Autonomous and integrated system, method and computer program for dynamic optimisation and allocation of resources for defined spaces and time periods

ABSTRACT

In one aspect, the invention provides a computing system for optimising and allocating bookings within one or more spaces in a venue, comprising an allocation module including an optimisation algorithm in communication with a processor and arranged to receive at least one booking request for a table or table combination and communicate with a database of other saved booking requests, retrieve the saved booking requests and combine the at least one booking request with the saved booking requests to form a pool of requests, retrieve constraint information and iteratively allocate each of the requests from the pool of requests to a table or table combination utilising the constraint information, wherein an optimised allocation instruction set of allocated bookings is produced.

TECHNICAL FIELD

The present invention relates to a system, method and computer programfor the dynamic optimisation and allocation of resources for definedspaces and time periods.

In one embodiment, the invention is directed to an online restaurantbooking system that optimises the use of space, time, and otheroperational considerations of a restaurant in order to optimise desiredoutcomes which may include optimising capacity, ambiance, preferredseating allocation, extended booking duration times, variable anddynamic pricing options, menu and course options and other quantitativeand qualitative criteria.

BACKGROUND

To better understand the inventive concepts and embodiments of theinvention described herein, an abridged history and of the restaurantindustry and known booking systems is described below, to assist inhighlighting the technical advantages of the claimed invention. Inparticular, the functional limitations and inherent technicaldifficulties required to overcome the limitations of the known art aredescribed below. The known prior art demonstrates the lack of anyeffective and workable technical solution to the fundamentally technicalproblems inherent in the optimisation, personalisation and integrationof the many aspects of managing a modern restaurant, particularly withregard to automated booking, ordering and automated aspects of servicein a restaurant.

Background—Manual Methods for Managing the Modern Restaurant a) TheBirth of the “Modern Restaurant” and A La Carte Dining

The Modern restaurant (i.e. the characteristics of a restaurant mostpeople would accept as being “typical”) developed in about theseventeenth century, when the enlightenment period (in European society)saw a growth of a literate travelling class that were able to read andhad “disposable income”, which in turn led to the emergence of a need toprovide services for this literate travelling class, such as lodging andmeals.

What began as a rudimentary meal provision service (usually as part ofproviding lodgings) developed into businesses that became solely focusedon the provision of meals. As time progressed and some businesses thatprovided meals became larger and more complex, they developed ways tosystematise the manner in which the business was operated to address theadditional complexities inherent in serving many people concurrently.Over time, small innovations were introduced, such as the provision ofdifferent tables for different groups of people (i.e. a move away fromcommunal eating) and the provision of menus (i.e. where people couldselect the meal they wished to eat). This move towards “personalisation”eventually developed, by the late 17th century, into what would berecognised nowadays as a “restaurant”.

The personalisation of the dining experience led to the systemisation ofcertain processes. The systemisation was achieved through the divisionof labour, for example, for larger restaurants, the person who seats acustomer (the Manager or Maître Di) at their table was different to theperson who took the order (waiter), who was different again from theperson who delivered the food to the table (food runner), who wasdifferent again from the person who cleared and reset the table and theperson who collected the payment (cashier). Through the division oflabour efficiencies were gained, but as with any process that requiresthe division of labour, there also grew a need to have moresophisticated overarching management and systems to manage andco-ordinate the various interdependent activities in the running of therestaurant. The requirement for management and division of labour sawthe development of many manually implemented methods for achieving manynecessary tasks, such as how to arrange tables for customers, how toseat customers, how to communicate to the kitchen which table the foodwas for, how to communicate to the bar which table the drinks were for,how to communicate to the food runner and bar staff which table theyneeded to deliver the food and drink to and many other processes. Theprocesses grew in an ad hoc manner, as different restaurants trialleddifferent ideas and also learnt from each other through observation,mentoring and staff movement.

One of the manual processes that was created that has stood the test oftime was the numbering of tables and the use of table numbers toidentify tables and their location within a restaurant so that theperson taking the order could advise the kitchen which table the orderwas for, who in turn could advise the food runner which table to deliverthe food to and so on.

During the process of creating table numbers the concept of tablecombinations was also developed being the joining of two or more tablesto create a larger table. The process of joining tables together wasdenoted by showing the table numbers of the tables joined linked by aplus sign. For example, if tables 1, 2, 3 and 4 were joined to create alarger table they were normally denoted as 1+2+3+4.

Some of the manual processes developed in the early 1900s are stillactively used today by restaurants. However, one specific process orconcept is integral to the other processes and is still widely usedtoday is the process of seating customers at “tables” or “tablecombinations”. It is this process that is at the heart of all knownsystems used in the “booking of a table” or the allocation of a bookingrequest to a table. It is this process and concept that is also the“bottle neck” for the development of new efficient, dynamic andautomated table allocations, outcomes and optimisation.

b) The Manual Concept of “Tables” and “Table Combinations”

The creation of the concept of “table combinations” provided flexibilityfor the restaurant to cater for smaller groups more efficiently by usingsmaller tables and then joining those smaller tables together to createlarger tables. The concept made it possible for a restaurant to usespace more efficiently as, for example, a restaurant did not have tocarry many different size tables to cater for different group sizes. Inother words, the concept minimised the possibility of having to allocatea booking of two people to a table of six when no smaller tables wereavailable which would have resulted in forgoing the potential incomefrom the use of the remaining four seats.

However, the concept of “table combinations” also inhibited andprohibited the “optimisation” of a space. For example, on Valentine'sDay a restaurant could potentially better optimise its space if itcomprised a floor plan of only tables of two. However, on say Mother'sday when whole families (groups of 4, 6 or more) comprise the majorityof bookings, a restaurant comprising all tables of two would beinefficient as when the tables are pushed together to create tablecombinations, the “gaps” or “spaces” between the tables of two are notrequired and the restaurant would be left with large empty areas withinthe restaurant.

A concept not immediately appreciated, even by many who work in therestaurant industry, is that the process of joining tables togetherresults in “table gaps” also being “joined together” resulting in largespaces within the restaurant remaining unused and hence not optimisingthe available floor space. As such, the number of tables and the size ofthe tables within a restaurant needs to be matched to the customerrequirements for each service if the space is to be optimised.

To allow a different number of tables for different services, occasions,days of the week some fine dining a la carte restaurants createdfurniture store rooms within their restaurant premises. This is similarto the way that restaurants overcame the problem of not knowing how muchfood or drink they would need for a service by creating cool rooms, dryingredient store rooms and beverage storage rooms. Some restaurants alsoadopted the use of folding tables or trestle tables or different sizetable tops that could be placed on the same table base to minimise thestorage area requirements for extra or different tables or when tableswere required to be added or removed to meet ever changing and variablebooking demands.

The inclusion of furniture store rooms within the restaurant premiseswas originally pioneered by fine dining restaurants as such restaurantswere more focused on how many people could be seated within theirrestaurant space during “one seating” as compared to casual diningrestaurants that overlooked this element, as dining durations werequicker and they could focus on turning tables over during a service.Further casual dining venues find it difficult to manually cope with thecomplexities of both the concept of maximising floor space and turningtables over (reusing tables) during a service.

From about the 1980's with the expansion of the hospitality industry,the growth in the number of cafes and restaurants, with more restaurantsbeing owned by investors compared to chefs and owner operators, theincrease in rental costs, the creation of restaurants in shopping mallsand high traffic areas where space is more limited, furniture storerooms within restaurants have become extremely rare.

c) Telephone as the Medium to “Book a Table”

Until the widespread adoption of instant communications technology, theidea of “booking” a table was a rare concept. That is, booking a tableat a restaurant only became a common occurrence from around the 1950'swhen households and businesses installed telephones. Before that time,there was simply no easy way to book a table at a restaurant, so it wasfar more common for customers to simply walk into a restaurant andrequest a table.

To take telephone requests to book a table, manual diaries weredeveloped for restaurants to note the details of the reservationrequests. These diaries only sought a small amount of information tomake the booking process quick and efficient as the table allocationprocess could be completed by the skill and expertise of the restaurantmanager. Specifically, the information collected merely comprised (seeFIG. 1a at 132):

-   -   a) the customer's name;    -   b) the number of persons for the booking;    -   c) the booking time (arrival time);    -   d) the customer's contact telephone number; and    -   e) a note as to any special requests for manual consideration.

Limiting the manual information collected for a booking made sense, asthere are limitations to the amount of information restaurant staffcould ask a person on the phone for efficiency and without the customerfeeling they were being interrogated for additional information.Further, the restaurant manager would have been incapable, based on therestaurant manager's time constraints and the manual complexityinvolved, to manually utilise precise and detailed information such asthe number of courses being requested, for each booking request.

The limited booking information collected via the telephone, however,was still supplemented by the specific and continued manual involvementand intervention of the restaurant manager. Specifically, at some pointprior to a dining service or on multiple occasions prior to a particulardining service, a suitably skilled person would review the bookingsreceived and determine whether any more bookings could be taken andwhich tables or table combinations the bookings would be allocated to.

The Restaurant Manager as part of this review and allocation of bookingrequests, would, amongst other things use their skill and experience toundertake some form of the following processes manually:

1. Review the customer booking name, booking size and special requests,their knowledge of the customer, their previous experience inaccommodating similar customer requests together with their knowledge ofthe restaurant and the outcomes required by the restaurant to allocatetables or table combinations to the various booking requests. The keyingredient in this process was the restaurant manager's personalknowledge and experience to determine:

a. which customers to allocate the best tables to, such as a table witha view;

b. which customers were regular customer and should be seated on abetter table than first time visitors;

c. which table to allocate to a special occasion booking to such as ananniversary, which may have been to a more private and intimate table orlocation within the restaurant;

d. which bookings were similar and allocate those similar styles ofbookings within one area of a restaurant. For example, bookings withchildren being allocated on tables next to each other and away fromreservations for tables of two which may want a more private andintimate table;

e. what times bookings finished to potentially book tables with similarfinishing times next to each other to minimise the adverse impact of onetable being reset next to a customer in the middle of their meal;

f. the allocation of certain types of customers dependent on theirspecific requirements (e.g. business people to tables that may have abigger gap or distance to the next table so that they have more privacy,etc.); and

g. whether customers have any special needs, such as the need to providea larger table or bigger chair space for a wheelchair patron.

2. While undertaking the above manual table allocation process ofbookings requests a Restaurant Manager also needed to be cognisant andhave a very good understanding of the spatial constraints of therestaurant if they were to maximise or optimise customer satisfactionwithin the physical constraints of the restaurant and the strategicrequirements of the restaurant. Specifically, the restaurant managerneeded an intimate knowledge of at least the following spatialcharacteristics of the restaurant:

a. Understanding the utility of tables in the restaurant, for example,which tables have a view or which tables offer greater privacy, whichtables are more intimate, which tables are more noisy or which tablesare less desirable as they are next to the kitchen door or at the backnext to the toilet;

b. Understanding which tables can be “moved” to create a bigger gap tothe next table to permit greater privacy if required; and

c. Understanding which tables can accept a wheelchair or a disabledperson.

3. Also, while undertaking this table allocation process the restaurantmanager had the opportunity to overlay staffing levels for that serviceand ensure that any table allocations are undertaken in a way that wasefficient from a staffing perspective, Specifically:

a. Splitting bookings allocations over different areas within therestaurant so that the workload is split evenly between wait staff;

b. Consolidating or condensing bookings over a smaller floor area withinthe restaurant when the restaurant is short staffed; and

c. Placing important customer bookings in a section or area where thestaff is more experienced, etc.

As such the manual allocation of a booking request to a table was, in anideal setting, a deliberate process that took into account information,skill and knowledge far beyond the simple information collected by thereservations staff over the telephone to achieve the desired outcome fora restaurant based on its strategy.

At the end of each booking allocation process, the restaurant managermay have also made notes on the manual restaurant diary advisingreception staff what times were still available and what booking sizescould still be accepted so that a person receiving a future telephonebooking request would know whether they could accept that booking orwhat alternatives they could offer. For extremely busy services arestaurant manager may have undertaken the review of table allocationsnumerous times before the particular service commenced as they kepttrying to rearrange allocations for greater efficiency, optimisation andto achieve their desired outcomes of the restaurant. As such, there wasno hard rule as to how many times this manual table allocation processwould be undertaken other than to suggest it was undertaken on an ad hocbasis.

As the process of answering a telephone to take a restaurant booking ismanual involving human interaction, each booking was being personallyhandled, such that, there was always the opportunity to reallocatebookings to different tables to ensure that a “Super VIP” could still beallocated their favourite table. As such, table allocations, when beingmanually allocated, allowed for booking allocations to remain dynamicand not static meaning previous table allocations were not necessarilyfixed and unchangeable.

As a last step prior to a service a restaurant manager could undertakethe allocation process one last time with full knowledge of all bookingrequests. As such, the restaurant manager was integral and invaluablethroughout the whole table allocation process for booking requestsreceived via the telephone.

The restaurant manager could also use their knowledge from the bookingallocation process at the beginning of a service to brief staff as towho the customers were that were allocated to tables in their respectivesections, the requests and requirements of those customers, if thosecustomers were regulars and if there were any particular things theyshould know about or do to create a perfect experience and service forthose customers.

How often a restaurant manager would apply their skill and knowledge orhow much time was allowed for the abovementioned allocationconsiderations, how effectively they were implemented, and whether theywere applied consistently, even within a single service, is difficult toquantify, for the simple reason that such considerations were notcodified per se but were taught or passed on from one person to anotherin the same manner as most other skills were traditionally taught. Thereis no formal course or specific text that teaches what specific factorsthat one must consider in the booking allocation process, how to assessthose factors and then how to prioritise or weigh those factors inmaking the booking allocation decision. Lastly, as this bookingallocation process was undertaken by different persons for differentrestaurants or different people within the same restaurant, theirpersonal preferences and experiences, including their underlying abilityto reallocate bookings in the most efficient manner, etc., meant that notwo persons would necessarily provide the same set of allocations. Assuch, it is highly unlikely that any restaurant applied any of the aboveconsiderations efficiently, effectively and without exception.

Notwithstanding the lack of consistency in application of these conceptsand considerations, the manual allocation of bookings to a “table” or“table combination”, if done correctly, is a sophisticated process thattakes into account the needs of the customer, the spatial constraints ofthe restaurants and the resources of the restaurant. Therefore, at itsbest, a table allocation process as practiced by a skilled,knowledgeable and motivated restaurant manager represented the manual(albeit imperfect) “solving” of a very sophisticated multi-variateproblem that comprised qualitative variables, spatial and otherquantitative variables and resource variables. It is fundamentally atechnical problem as it requires the solving of a problem, which is notstrictly a mathematical problem per se, but rather is a logic problemthat requires a multi-step algorithm that takes into account manyseparate and sometimes conflicting requirements.

Even with the best of intentions and a high level of skill andknowledge, it was difficult for a restaurant manager to allocatebookings in an optimal manner, even for a smaller restaurant, as thedifferent considerations, permutations and potential table combinationsare impossible to properly consider, irrespective of the experiencelevels, training, skill or wisdom of the restaurant manager within areasonable period of time. It is widely understood and acknowledged thatthe profit margins in restaurants are quite small (generally profitmargins are less than 5%) so there is very limited time that anyrestaurant could afford in additional wages for the restaurant manageror another person could spend undertaking this booking allocationprocess. As such, this manual process was not only appliedinconsistently but would have rarely been optimised.

With the expansion of the hospitality industry and with no formaltraining available as to how to allocate bookings to tables these skillscontinue to be underdeveloped and rarely applied, except perhaps in somefine dining restaurants.

Known Computer-Implemented Booking Systems Art d) Practical Prior ArtUsing the Internet as the Medium to “Book a Table”

With the uptake of the Internet by consumers and businesses, companiesbegan looking at ways of improving, streamlining and removing the manualprocesses of taking restaurant reservations via the telephone, by usingthe Internet as an alternative communications medium.

OpenTable (www.opentable.com), the world's most popular and largestonline booking system, was one of the first available online systemscommencing internet and online restaurant bookings from about July 1998.Today, there are hundreds, if not thousands of companies offering onlinerestaurant reservation and booking services around the world including:ResDiary, Yelp, La Fourchetta (“The Fork”), Chope, Tock, Bookatable,EZTABLE, Resy, Zomato, Zurvu, Respak, Seven Rooms, etc. Online bookingsservices have been available for the last 20 years and have created anew highly competitive multi-billion dollar industry comprisingcompanies who continue to spend large amounts of money in research anddevelopment trying to improve their systems and gain a competitiveadvantage. However, despite the passing of some 20 years and thecompanies' commitment to research and development, the underlyingprocess which all restaurant booking companies use in their software forthe collection of booking information and the allocation of bookingrequests to tables is substantively identical with no significant orsubstantial improvements having been made in the last 20 years.

As the differences in table allocation methodologies for all knownbooking allocation systems is very small, the companies differentiatethemselves by the addition of features that do not relate to the coreproduct of real time booking allocations.

All known systems in use today allocate each booking request to a tableor table combination immediately upon receiving the booking request andthe booking allocation, once made, becomes static, fixed and cannotchange. The static and permanent allocation of a booking to a table ortable combination acts as a “barrier” to the efficient allocation ofsubsequent booking requests.

Also all the prior art online restaurant reservations systems use a verysimilar approach with regard to the quantum of information collected,the type of information collected and the process of using the collectedinformation in the allocation of a booking to a table.

Specifically, the customer information and details requested andcaptured by known on line booking systems is identical to theinformation previously collected when booking requests were made usingthe telephone. As such, online booking systems offer no greatersophistication in the information collection for booking requests.

All online restaurant reservation systems, without exception, use a“static” allocation process to allocate each booking to a table or tablecombination as each booking request is received and once a booking hasbeen allocated to a table remains fixed at that table without furtherchange or consideration of subsequent bookings. This “static” allocationapproach creates numerous problems and inefficiencies that the prior arthas not been able to resolve or offer an alternative.

Without the benefit of manual intervention and the knowledge and skillsof a restaurant manager, Internet table reservations systems and bookingallocation procedures, are in fact significantly inferior to the manualtelephone booking allocation procedure, which required manualintervention.

e) Known Systems Only Allow for a “Fixed Number of Tables” to beIncluded in the Allocation Solution Pool

All available online restaurant booking systems can only consider afixed number of tables which are then placed into a list or lists of“tables and table combinations”.

Known allocation software operates with the constraint that a restaurantoperates with a finite set of tables, being the tables located withinthe restaurant. By definition this constraint means that the restaurantfloor space cannot be optimised. For example, when a table combinationis created to cater for a larger booking and tables are physicallypushed together to create the desired table combination, unused space iscreated. By definition, the restaurant space cannot be optimised as theadditional space created by the joining of tables is not utilised. Toprovide a numerical example, if there exists a row of five (5) tables oftwo people, there are at least four (4) gaps between the tables of two(2)—when the tables are combined to create a table of ten (10) toaccommodate a booking of ten (10) people, a large gap is created by theformation of the pushing together of the tables. The gap creates thepotential to bring in at least one additional table of two (2) and takea further booking of two (2). However, known software applications haveno mechanism to recognise and fix this problem. This sub-optimal resulthighlights a significant inefficiency.

In other words, the known booking systems are inherently unable to addor remove tables during the booking allocation process.

f) Prior Art Requires the Manual Compilation of “Tables and TableCombinations” to Form the Total Number of Tables in a Solution Pool

The determination of the total number of tables to place in a restaurantand the lists and permutations of “tables and table combinations” withinthis practical prior art is a manual process and there is no check orcontrol process or mechanism as to the appropriateness, objective orotherwise of the lists of tables and table combinations.

The information that needs to be provided for known softwareapplications to operate are:

1. A manually determined total number of tables to place within therestaurant;

2. A manually determined list of all tables and table combinations inorder of preferred allocation priority; and

3. A prioritised list of tables and table combinations that include themaximum and minimum booking numbers that can be allocated to each tableor table combinations.

Once determined, the list of tables and table combinations for a serviceor period cannot change and the “pool of solutions” from which toallocate a booking cannot change nor can the order of priority in whichtables are allocated.

The determination of the number of tables and the lists of “tables andtable combinations” are manually prepared and there is no checkmechanism to ensure the appropriateness or efficiency of the totalnumber of tables selected or the list of tables and table combinations.

g) Known Systems Only Offer “Static” and “Linear” Allocation” ofBookings to Tables and Table Combinations in the Solution Pool

The universally applied methodology for the allocation of bookings torestaurant tables is through the manual creation of a prioritised staticlist or lists of “tables and table combinations” to which a simple“look-up” style formula is applied to find the first available table ortable combination to which a booking has not been previously allocated.This approach is referred to as being “static” and “linear” as it isbased on the procedure of allocating booking requests on an “immediate”,“First-In; First-Seated” basis, and once the table allocation has beenmade the allocation remains “permanent” and fixed and is not changed orreconsidered during any subsequent booking request.

No better system has been applied since the original immediate, static,“First-In; First-Seated” method for the allocation of bookings to tablesor table combinations was developed in the late 1990s, whencomputer-implemented booking systems first became available.

FIG. 1a is an image of a cover 134 and a sample page 132 of a diaryutilised to manually record bookings. FIG. 1b is a screenshot fromRespak (www.respak.com) showing a static prioritised table ranking andallocation list 136. FIGS. 1c and 1d are screenshots 138 and 140respectively from the ResDiary (www.resdiary.com) system showing the useof a similar static table combination list and the prioritising of thetable combinations. FIG. 1e are screenshots of the input for the tablecombinations into the OpenTable (www.opentable.com) system 142 and 144.OpenTable varies from the other abovementioned static priority lists asOpenTable does not allow the user to input the priority of the staticallocation list the system, rather, it automatically allocates a bookingto the smallest best fit “table number” or “table combination” numberavailable and then moves to the next smallest best fit table number ortable combination number. As such, the OpenTable approach sets thepriority through the use of the table number as the ranking system. Inmany ways the approach by OpenTable in applying the allocation on tablenumbers places greater restrictions on a restaurant. The control of theprioritisation of bookings by table number under the OpenTable systemmeans restaurants are now restricted from using table numbers which aresolely focused on the physical location of a table within therestaurant.

For any given booking request the abovementioned systems do not considerpreviously allocated tables or table combinations. This methodologycreates inefficiencies with regard to any possible optimisation.

h) Prior Art Requires Manual Intervention as Prior Bookings arePermanent, Fixed and Immovable

Internet-enabled static booking allocation software requires more manualintervention than telephone booking requests as each booking request isimmediately allocated upon the receipt of the booking request.

The creation of online restaurant booking systems have had the benefitof reducing time required by staff spent on the phones as when bookingscome through the internet a receptionist's work load is reduced.However, restaurants using such systems are in a disadvantageoussituation when it comes to optimisation of the restaurant space as theyare required to manually review the continuous static allocations madeby the system more frequently to ensure that subsequent Internetbookings are not rejected by poor prior allocations by the system.

i) Known Systems Have No Knowledge of Restaurants SpatialCharacteristics

Known systems have no ability to take any of the spatial characteristicsof a restaurant into account when making a booking allocation to atable.

The spatial characteristics with a restaurant that could be used toallocate bookings can include; special tables such as window tables orsections, classes or areas with a view and ranking of all tables. Theseprocesses are a necessary part of the daily activities of a restaurantmanager.

j) Known Systems Cannot “Sell” a Table or Offer Specific Tables forSelection by a Customer

Known systems cannot re-arrange allocated bookings to sell or offer aspecific table to a customer.

Known systems also cannot control the capacity of sub-groups of tablesand table combinations—that is, known systems cannot withhold a specifictable or table combination or areas for sale with confirmedavailability.

k) Known Systems Cannot Consider Customer Requests and CRM Information

Known system do not have any ability to autonomously receive, processand/or act on any customers requests, customer history, customerpriority or any other details into consideration as part of the bookingallocation process.

l) Known Systems Do Not Permit a Customer to Personalise TheirExperience

Allocating bookings to tables and table combinations on a “immediate”,“static”, “First-In; First-Seated”, “permanent”, basis results in a verysimple process in the allocation of bookings which does not permitbookings to be prioritised or allocated based on other constraints, suchas, customer status, customer time duration requirements, customer menuselection and course selection nor the ability to charge a customer adifferent amount of money for a change to the standard constraintsattached to a booking.

Known systems do not recognise that a restaurant booking can represent abooking where a person wishes to tailor and personalise their entireevening so that their experience can be more bespoke and unique.Customer Personalisation Inputs include:

-   -   1. Permitting customers to select their specific table, or table        type or table location as well as time durations, menus and        other constraints;    -   2. Permitting a customer to personalise their occasion with the        addition of third party services not normally offered by        restaurants, such as, flowers, guitarist, a box of chocolates to        take with them at the end of the meal;    -   3. Permitting a customer to change the order of service normally        offered by a restaurant;    -   4. Permitting a customer to request a particular waiter or to        request their own personal waiter; and    -   5. Permitting a customer to personalise their occasion, for        example with, a champagne bucket with a bottle of champagne on        their table on arrival, a message written on their dessert        plate, a specially created dish or a specially sourced bottle of        wine.

m) Known Systems Cannot Factor Time as a Perishable Resource in theAllocation of Booking

While time management has been considered in the management of tablesand table combinations, prior art solutions have only considered time asone standard unit of measure for all different bookings irrespective ofany further considerations such as different menus that may be offeredby the restaurant and the number of courses that may be planned to beconsumed by a customer. The prior art is unable to consider ordiscriminate between different menus, different number of courses,different group sizes, different occasions or other factors that need tobe understood and considered for a more accurate allocation of time to abooking.

The prior art does not factor the time required to reset a table beforeit can be reused as a constraint in the optimisation of a restaurant'scapacity as a discrete unit. Further, the prior art cannot vary the timetaken to reset a table before the table can be reused for the nextbooking depending on the number of staff that are working on aparticular shift or service or the style of restaurant or any othervariable relevant to the restaurant.

The prior art does not factor the time people take to consume a mealbased on parameters of menu selected, number of courses, group size,occasion and then use this information to provide recommendations or toautomatically update the system for future booking duration timeallocations.

The prior art does not factor the time taken by a restaurant to reset atable and how the process of a resetting a table can be improved orreduced so that the valuable resource of time is optimised.

The prior art does not consider time as a variable that can be optimisedto increase the utility to the customer while improving the efficiencyof the restaurant. For example, if a customer wishes to stay longer inthe restaurant without increasing their spend they are reducing theavailable revenue potential of a restaurant. The prior art cannot offeradditional time for a booking for an additional charge if a bookingwishes to stay longer or offer a discount or benefit if a booking iswilling to commit to stay for a reduced time.

n) Known Systems Cannot Offer Dynamic Pricing and Dynamic ProductOfferings in the Booking Allocation Process

Known systems do not have the ability to rank and discriminate therelative or perceived utility or value or rank of a table, area,subarea, sections, classes or location within a restaurant. For example,a table with a view being of perceived higher utility and desirability,and hence value, than a table in a back corner next to a toilet.

o) Known Systems Cannot Control Capacity (Table Availability) Offered ByMenu or Other Constraints so as to Permit the Application of YieldManagement in the Booking Allocation Process

By definition yield management involves and requires the strategiccontrol and allocation of capacity (in this case, a restaurant's tables,chairs and stools) to sell the right menu with the right number ofcourses to the right customer at the right time for the right durationof time for the right price. In this regard, the limitations of staticlinear combinatorial priority lists are unable to control capacity andadopt sophisticated yield management techniques as part of theallocation process.

As known systems cannot effectively control capacity or the allocationof capacity, attempts at constraint management or yield management havebeen limited to simple manual promotions offering discounts withoutreference to the particular tables or table combinations that thesepromotions could be applied to and have been limited to discountpromotions such as:

-   -   1. Static pricing such as offering a discount for an early        booking;    -   2. Static product offerings such as a free glass of wine for an        early booking;    -   3. Static pricing such as a 20% discount for pre-theatre dining;        and/or    -   4. A booking fee charged for the selection of a preferred        service such as a Friday or Saturday evening.

Known systems do not and cannot consider any yield management measureslike revenue efficiency. Revenue efficiency is the product of theutilisation of capacity in a space for a period of time measured inunits of time (including the ability to bring in additional tables andchairs or the ability to remove tables and chairs from a restaurant)multiplied by the revenue generated from the space for the serviceperiod as compared to the revenue that could have been generated duringthe service period if all sales, discounts and promotions were assumedto have been sold at their normal recommended retail price.

The prior art as it relates to yield management was succinctly outlinedby Heo, Cindy Y., Ph.D, Associte professor, School of Hotel and TourismManagement, The Hong Kong Polytechnic included in the publication“Revenue Management for Hospitality and Tourism”, by Patrick Legoherel,Elisabeth Poutier and Alan Fayall, published May 2013, chapter 8,“Restaurant Revenue Management” page 2. Dr Heo writes:

-   -   “Revenue management generally involves segmenting customers,        setting prices, controlling capacities and allocating        inventories to maximise the revenue generated from a fixed        capacity” [underlining added]

In this regard, the restaurant yield management prior art makes noreference, explicit or implicit, to controlling capacities such aswindow tables, preferred tables, high demand tables or to optimising theallocation of bookings to tables. The prior art merely attempts to limitthe amount of bookings taken for a particular time interval to ensurethat a restaurant is able to service the amount of bookings taken at aparticular booking interval using a list of manually created tables andtable combinations.

Further, the allocation of inventories in the prior art is limited tosegmenting a service period into fixed period seating periods which initself does not address the issue where a peak dinner booking time for arestaurant being 7:30 pm where the two selected seating periods being 6pm to 8 pm and 8 pm to 10 pm. As such the prior art does not address thepeak booking time of 7:30 pm and cannot set an appropriate price for a7:30 pm dinner which may provide a better revenue and contribution thantwo separate bookings, one at 6 pm and one at 8 pm. With ineffectivecontrol of capacities and inventory allocation the prior art could notsegment customers and set changing or dynamic pricing.

Dr Heo compares yield management in Aviation and its applicabilitywithin a restaurant environment and concludes:

-   -   “However, non-traditional revenue management industries such as        restaurants have unique business characteristics”, page 1;    -   “These unique characteristics of restaurants pose special        challenges to restaurant operators and consequently require more        creative revenue management strategies.” Page 2;    -   “However, the revenue management strategies that are currently        implemented by restaurants merely focus on discounting prices        during low demand periods”, page 2; [underlining added]    -   “Restaurants have the potential to incorporate revenue        management practices in their operations, but cannot simply        apply the same revenue management strategies as those used by        airlines and hotels” page 7. [underlining added]

While Dr Heo suggested the possibility of applying certain types ofyield management techniques to the restaurant industry, her conclusionwas that the application of such techniques presented a number ofchallenges, however Dr Heo failed to offer any solutions to thechallenges identified.

As Dr Heo outlines, even in “manual” form (i.e. a person performingabstract calculations), past attempts to apply the same revenue andyield management strategies as those applied by airlines and hotels torestaurants result in a number of challenges. As such, the applicationof yield management techniques to a restaurant environment is not asimple and logical extension of the airline and hotel yield managementtechniques. The reasons why restaurants offer far greater challenges foreffective yield management than airlines and hotel include:

a. Airlines and hotels have known capacities, for example the additionof one more chair or one more room within an aeroplane or hotel is notpossible so they have a known and fixed capacity. In a restaurant, theaddition of one more chair or one more table, or a different tablelayout means that a restaurant does not have a fixed, easilyidentifiable, known and manageable capacity—the variable nature ofcapacity in a restaurant results in an exponential growth in possibleoutcomes;

b. Airlines and hotels have a known physical capacity such that eachseat or room is known and is usable. With a restaurant. Many variablesmay affect total capacity, beyond the number of chairs and tablesavailable. For example, a restaurant may contain external seating whoseavailability is subject to the weather and not usable during someservice periods;

c. Airlines and Hotels have a known physical environment; for example,the seating configuration within an aeroplane is not changed in linewith booking requests. Specifically, a booking request for 10 people fora particular flight does not require that all customers be groupedtogether in adjoining or adjacent seats—each person can take anyavailable seat within the aircraft. In other words, there is limited orno requirement to reconfigure seating on the aircraft to accommodate thebooking request. Similarly, with a hotel, rooms are of a known size withknown physical attributes and if a booking cannot be accommodated withinone room the booking can generally be allocated a different room withsimilar amenities. Moreover, there is no requirement for the room to beadjoining. With restaurants however, a large number of constraints limitthe ability of a restaurant to allocate a table. For example, when arestaurant receives a booking request for 10 people, the 10 people mustbe placed on the same table and cannot be randomly placed on tables orseats anywhere within the restaurant. Further, the restaurant bookingalso requires that their table is separated from other tables forprivacy. The problems and further difficulties faced by restaurants ascompared to airlines and hotels if further compounded by this additionalcomplication;

d. Airlines and Hotels have known configurations from one flight to thenext or one day to the next while restaurants do not have knownconfigurations. For example, the table configuration on Valentine's Daymay be for all tables of two yet on a different day like Mother's Day itmay be for larger tables making the control of capacity for restaurantsmore complex than that of an airline and a hotel;

e. Airlines and Hotels have a known duration of service. Specifically,an airline knows the length of a flight and flight time. This is similarto a hotel that offers rooms for fixed durations. With a restaurant, thecomplexity is much higher than that of an airline or a hotel as thelength of meal durations is variable and unknown and based on manyunknown variables to a restaurant such as occasion, group size, numberof courses to be consumed, etc. This further unknown adds additionalcomplexities to the restaurant capacity control problem;

f. Airlines and Hotels have known arrival times and known departuretimes. Generally speaking all flights take off at a specific time andall flights arrive at a specific time. With a restaurant environment,for example, you have people arriving for dinner at 6 pm, 6:30 pm, 8:pm, 8:30 pm and then leaving at random times making the control ofrestaurant capacity unpredictable and more complex;

g. Airlines and Hotels do not have to consider walk-in customers withintheir capacity control considerations. Firstly, once an aircraft leavesthe airport its capacity is closed as it cannot take any more customers.Similarly, hotels do not rely on walk-in customers. With manyrestaurants, however, a significant part of their business may bewalk-in customers and a restaurant has to consider whether its walk-incustomers offer greater revenue potential than booked customers and howmuch of its capacity it should reserve for walk-in customers. Just as arestaurant should consider what bookings to accept prior to service andhow the restaurant table layout should be configured to ensure that ithas flexibility to accept walk-in customers;

h. Peak times for an airline and hotel last are longer than a restaurantand therefore are easier to manage. Specifically, peak-times forairlines and hotels include as a minimum of at least one complete flightor one complete day, while peak times for a restaurant may only be atsay 7:30 pm on a Saturday night which is far more difficult to control.Restaurants therefore need greater accuracy in the planning and controlprocesses;

i. Service provisions for an airline and for a hotel are relativelystandardised within each class as the food beverage and refreshments arestandardised as is the make-up of the room. With a restaurant servicethe standards, in many cases include the selection of food and beveragesfrom a menu (a la carte service). Further when selecting items from amenu, customers are also permitted to also advise cooking instructions,if they have allergies, dietary requirements, ordering at their ownpace, different requirements for information about the food or otheritems meaning that duration planning is further complicated and hasgreater variability; and

j. Competition and substitute products are more readily available withina restaurant environment than with airlines and hotels so the process ofdelivering different promotional offers is more time sensitive thanairlines and hotels. As such restaurants require more creative revenuemanagement strategies than airlines and hotels.

As a result of the above complexities the prior art has not been able toapply airline or hotel yield management strategies to restaurants.Further, references in the prior art to yield management as applied torestaurants has been incorrect as correct yield management requires thestrategic control of inventory to sell the right product to the rightcustomer at the right time for the right price. The restaurantmanagement strategies that are applied by the prior merely focus andapply discounting prices and complementary prices during low demandperiods. Discount pricing techniques including promotions like “happyhour” and “early bird dining” are not based on yield management butrather on simple ad hoc discounting.

The prior art process of determining the right mix of tables and optimalmix of tables within a restaurant does not address any concept of“dynamic capacity”. The prior art approach proposes that it is best tohave a fixed table for 6 people if a booking is expected for 6 people. Apredetermined estimate of the correct mix of tables only serves as arough approximation of limited value in the control of capacity as itdoes not allow for dynamic capacity.

The prior art does not provide a process to control duration time otherthan applying a standard and universal time duration period for allbookings. As a result of this standard duration time, as an example andin simplistic terms, restaurants have merely focused on trying toachieve two seating periods on busy services such as on a Saturdayevening, one between 6 to 8 pm and another from 8 pm to 10 pm. By takingthis approach, restaurants have denied themselves the opportunity ofimplementing dynamic pricing such as charging a higher amount for abooking that specifically requires a 7:30 pm time. Through this practicerestaurants cannot adopt proper revenue management techniques and yieldmanagement techniques such as dynamic pricing and differential productsand menus and remain limited to simple discounting on off-peak or lowdemand times.

The prior art apart from teaching of the difficulties in applyingairline and hotel yield management strategies to restaurants cautionsrestaurants from doing so. Renza Etemad-Sajadi and Arnaud Durand, intheir paper “Revenue Management practices in restaurant industry vsairline/hotel industries” published in the International Journal ofQuality and Reliability Management, Vol. 35, Issue 4, 2018, pages846-856 (Emerald Publishing) concluded:

-   -   “Despite the fact that revenue management practices are well        known and accepted for airline and hotel industries, they are        not acceptable to clients in restaurant industry. The consumers        seem to accept the rules of price variability in airline and        hotel industries, but they do not see the benefit for them in        restaurant industry”.

However, the prior art also appreciated the importance of a restauranthaving the right table mix. Sheryl E. Kimes, in “Restaurant RevenueManagement” Cornell Hospitality Report, 4(20, 4-34 (2004), states:

-   -   “One of the major advantages of a table ix that matches the        customer mix is that it takes much of the guesswork out of which        party to seat at which table”    -   “Research has shown that an improved table mix can increase        revenue potential by up to 35 percent without an increase in        customer's waiting time”

Dr Gary M. Thompson in his paper “Optimising Restaurant Tableconfigurations: Specifying Combinable Tables, in Cornell Hotel andRestaurant Administration Quarterly 44(1) 53-60, review the processes bywhich table mix and table configuration could be optimised.

The prior art focused on attempting to estimate and determineconfiguration and table mix prior to the receipt of a booking request ascompared to determining the configuration and table mix upon receipt ofa booking request. As such the prior art is inherently unable to addressthe issue of “dynamic capacity”—that ism, allowing restaurants to varycapacity to better accommodate an increase or decrease in tables.

Due to the difficulties in implementing yield management within therestaurant industry and the perceived adverse customer reaction todifferential or dynamic pricing within the restaurant industry the priorart has not been able to find a solution for the introduction of yieldmanagement to the restaurant industry despite the proven success ofyield management within the aviation, hotel and car rental industries.

p) Known Systems Cannot Offer Complete and Seamless Integration Betweenthe Different Restaurant Systems

Know systems do not offer effective integration between discount andpromotional apps, restaurant booking widgets, apps and systems,electronic menus, point of sale systems and payment solutions as thebooking allocation process requires continuous manual intervention toachieve the desired outcomes of the restaurant or offer a diningexperience that can be tailored to a person's specific requirements.

Known restaurant systems are stand alone, with many independent anddifferent systems with different software and hardware solutions beingused to bring together a very cumbersome and ineffectively integratedsolution for the optimisation and management of a restaurant. In theknown art, the use of different and potentially overlapping systems isinefficient and requires significant manual co-ordination. For example,pre-booked customers, walk-in customers and home delivery orders aregenerally handled in different manners and through different systems,yet they each impose different demands and requirements on the abilityof a restaurant kitchen to process orders. If orders are notco-ordinated correctly and managed possible delays in preparing numerousorders could create detrimental effects which could damage thereputation of the restaurant and may even result in the demise of therestaurant.

Known systems also fail to provide an integrated system for the offeringof gift cards or the acceptance as a form of pre-payment to permit astreamlined and autonomous booking and payment process.

Known systems also fail to adequately apply information from CustomerRelationship Management (CRM) systems in the allocation of tables tocustomers to better tailor the customer's booking experience or bygiving priority and allocating better tables to more loyal customers orcustomers who could bring a better social media outcome for therestaurant.

The multiplicity of systems offered by the prior art and the numerousmanual interventions required teaches away from the use of a singlecentral system from which all other restaurant systems can logically beintegrated into to form a complete, integrated and autonomous restaurantsystem. This is despite the obvious benefits of an integrated andautonomous restaurant booking allocation process and an integrated andautonomous solutions to increase the revenue of a restaurant, the bettermeeting of customers' requirements, reducing costs, forecasting demand,adjusting operating constraints, developing resource requirements andstaff requirements, providing additional services such as tailoring acustomer's experience, home delivery and gift cards.

To put it another way, as the prior art has not been able to improve thetable allocation process many companies providing on-line restaurantreservations have stated that there is no better way to allocate bookingrequests to tables than the processes already available. Further, manyof the companies have abandoned trying to improve the booking allocationprocess and are now focusing on additional features to their systems. Togive a racing car analogy of what is happening with many online bookingsystem providers; they have abandoned trying to make their racing car gofaster as they do not know how to do it, and are now focusing onfeatures such as adding metallic paint, tinted windows, mag wheels, rearspoilers, which, if anything merely add to the manual processes ofmaintaining the car without any additional benefits to the speed of theracing car. That is differentiation by appearance than differentiationby performance of the core characteristic. Specifically, most, if notall, online restaurant booking systems now offer are “integrated” CRMsystem. However, these CRM systems do not and cannot be linked and formpart of the table allocation process. An example of the inefficiency ofthis prior art is that while many of the prior art CRM's record acustomers' favourite table, none of the prior art systems can use thisinformation in the booking allocation process to allocate a loyalcustomer to their favourite table.

q) Prior Art Recognised the Problems of Static Table Allocations andSought to Find a Dynamic Table Allocation Solution (Vidotto, 2009)

Vidotto in his thesis entitled “Managing Restaurant Tables UsingConstraint Programming”, National University of Ireland, November 2007,sought to find a dynamic booking allocation process. Dynamic allocation,in this context refers to the process whereby each time a bookingrequest is received all previous bookings are unseated and then allbooking requests are considered contemporaneously in an attempt to findan optimal table allocation solution. In theory a dynamic allocationprocess should permit the restaurant to take more bookings as previouslyallocated bookings acting do not act as “barriers” to a more efficientallocation of booking requests to tables.

Vidotto acknowledges the existence and the static nature of thispractical prior art on page 1 in his theses where he states:

-   -   “On current systems, booking and floor allocations are done        manually, and require experienced personnel. The first        computerised table management programs have recently started to        appear in some busy restaurants, but most of them provide no        advice to the user, and do not support dynamic table        reallocation.” [underlining added]

In his thesis Vidotto also outlines the purpose of his research and histhesis as an attempt to find a practical solution to the prior staticallocation process as well as offering assistance in the management of arestaurant on page 1 where he states:

-   -   “Restaurant table management could be improved if we could        develop software that can be used by staff with less expertise        and knowledge, and that can help the automation and optimisation        of the (dynamic) allocation process” [underlining added]

However, the proposed solution put forward by Vidotto is incapable ofthe “optimisation of the (dynamic) allocation process”. The bestVidotto's proposed solution can achieve is to maximise the number ofbookings taken on the manually pre-determined pool of table and tablecombinations that form the total pool of solutions from which a tableallocation can be made.

Vidotto also teaches away from the introduction of a large number ofvariables and constraints within his proposed booking allocation formuladue to the impractical computational times required by his proposedformula as the number of variables and constraints increase.

r) Constraint Programming as the Only Solution to the Dynamic BookingAllocation Problem

Vidotto clearly delineates the scope of his work in his thesis, with thetitle being:

-   -   “Managing Restaurant Tables Using Constraint Programming”

Vidotto then states in his “Abstract”:

-   -   “the core of the issue is a complex dynamic combinatorial        problem”, [underlining added]

Vidotto reinforces his view as to what he believed the solution to thedynamic allocation problem was on page 1 where he states:

-   -   “In computer Science terms, table management is an online        constrained combinatorial optimisation problem”. [underlining        added]

While in Chapter 3, page 27, Vidotto introduces his specific view ofconstraint programming where he states:

-   -   “A constraint program represents the problem as a Constraint        Satisfaction problem (CSP), and then solves the CSP with a        combination of constraint propagation and search (typically        backtracking search)”    -   “In CP terms, representing a problem means selecting a set of        decision variables, each with a domain of values, and a set of        constraints over these variables that restricts the values that        subsets of variables can take”. [underling added]

From a technical perspective, Vidotto only describes the use of theknown mathematical formula and technique of “constraint programming”.

Based on the above, it is clear that Vidotto's work is solely based onand revolves around the use of tables and table combinations as thesolution or domains within a CSP to define and solve the restauranttable management problem.

Bossert, in patent application publication no. 2009/0292566 A1,published 26 Nov.2009 clearly indicated and noted that “constraintprogramming” was the base upon which his capacity calculation model wasbuilt, thus following Vidotto.

Bossert not only acknowledged the existence of the theoretical art of“constraint programming” for the dynamic allocation of bookings totables in his cited art in paragraph [0047] of his patent application,but also acknowledged within that paragraph his use of the prior art ofconstraint programming as the solution for the capacity determinationand the allocation of booking requests to tables. Specifically, atparagraph [0047] Bossert states:

-   -   “Methods to perform the calculations of capacity module 60 exist        in the prior art. For example, mathematical and logical        constraints can be used to describe the seating capacity of a        restaurant whose tables may be reconfigured and constraint        programming solution procedures can determine or at least        estimate whether the restaurant has sufficient capacity to        accept a set of table reservation requests”. [underlining and        bolding added]

Form the above it is clear that Vidotto and Bossert disclose “constraintprogramming” as the only known system and mathematical approach that cansolve the problem of dynamically allocating booking requests torestaurant tables.

s) Definition of Constraint Programming

In Chapter 3, page 27, Vidotto introduces his specific view ofconstraint programming where he states:

-   -   “A constraint program represents the problem as a Constraint        Satisfaction problem (CSP), and then solves the CSP with a        combination of constraint propagation and search (typically        backtracking search)”    -   “In CP terms, representing a problem means selecting a set of        decision variables, each with a domain of values, and a set of        constraints over these variables that restricts the values that        subsets of variables can take”. [underlining added]

It is noted that “constraint programming” refers to the construction ofa specific type of mathematical formula. While “constraint programming”uses “constraints” or “constraint information” to classify or filter thevariables within the “constraint program”, the use of constraintinformation in order to determine a solution does not imply that anymathematical or logical program that utilises constraint information isan example of “constraint programming”. “Constraint programming” refersto a specific and particular type of mathematical “process and formula”to be used to solve the problem and not to the use of individualconstraints within any formula or any mathematical equation.

In other words, the reference to “constraint programming” in the priorart is a very specific term of art in the field of mathematics andcomputer science. Vidotto's work is based on the use of CSPs to defineand solve the restaurant table management problem.

The term “constraint information”, in contrast, is not a term of art inthe context of mathematics or computer science. The term “constraintinformation” is to be ascribed a plain meaning to those skilled in theart, namely those who work and operate restaurants or analogousenterprises where physical space needs to be managed in some manner. Theuse of the term “constraint information” is intended to includeinformation that defines the physical characteristics and limitations ofthe space (which may be broadly characterised as the “resources”available, and also the desired outcome with reference to therestaurant's strategy or the customer experience (e.g. a VIP customerwishes to dine at a particular table)). These disparate yet interrelatedpieces of information form a collection broadly referred to as the“constraint information”. This is a very different concept from themathematical and computer science concept of “constraint programming”.

By definition, the constraint satisfaction problem is one where allpossible solutions are determined from a fixed list of tables and thenvalues and constraints are set so that when a new variable (bookingrequest) is received a new search can be undertaken to find the best apre-defined and developed solution. In this regard, on page 88, Section3.1.1, Vidotto outlines his specific implementation of the CSP asfollows:

-   -   1. Decision Variables: these are the booking requests, defined        as the number people or party size of the booking    -   2. Values: A list of all tables and the number of people that        can be seated at those tables    -   3. Domains of Values: (solution pool) an exhaustive list of all        the possible “tables and table combinations” (similar to the        solution list created by the practical prior art) from which the        solution can be found as manually determined from a finite and        fixed number of tables    -   4. Constraints: (constraints are applied to variables for which        a solution is sought to restrict to limit the solutions (values)        that the variables can take. Alternatively stated, a list of the        different conditions that must be met prior to the allocation of        a booking to a table or table combination, these conditions or        constraints may include:        -   a) booking start times;        -   b) no-overlapping;        -   c) acceptable booking sizes; and        -   d) time allocated to a booking on a table.

Vidotto acknowledges that the computational time required to solve a CSPis excessive and not commercial in his thesis at pages 89 to 90. In anattempt to overcome these problems Vidotto introduces “Pre-solvingChecks”, “Symmetry breaker constraints” and “Ordering Heuristics”,making the CSP he implements very complex, such that the only people whocan understand the underlying mathematics and logic would bemathematicians with specific knowledge of the field of constraintprogramming; something that is extremely distant and remote to theunderstanding of a Restaurant Manager.

In the conclusion to his thesis titled “Managing Restaurant Tables UsingConstraint Programming”, Vidotto confirms his thesis is focused onconstraint programming as the potential solution to the management ofrestaurant tables (no mention is made about the management of therestaurant space) where he states on page 232:

-   -   “Constraint programming can be used as a tool to support,        enhance, and automate uncertain and highly dynamic restaurant        table management” [underlining added]

Further, Vidotto states on page 238:

-   -   “The research is valuable for restauranteurs, but also for the        constraint programming community. Restaurant table management        has no history in the literature of constraint programming. We        believe that this dissertation represents a good and already        advanced baseline for tracking an interesting and novel, dynamic        and highly uncertain problem.” [Underlining added]

Lastly, on page 238 Vidotto states:

-   -   “In scientific terms, our use of constraint programming        algorithms for optimised reconfiguration in the face of        uncertainty is also novel.”

Vidotto's developed and proposed CSP, and CSP's generally, in thecontext of managing restaurant tables, have not been applied in anypractical application and have never progressed beyond the realm oftheory. Also the limitations of constraint programming preventconstraint programming, as a concept, from being capable of beingreduced to practice in industry. These limitations include but are notlimited to:

-   -   1. A table allocation can only be made from the pool of        solutions defined as “Domains” within the CSP. Further, these        domains are manually calculated and inputted within his        constraint satisfaction problem called “Tables and Table        Combinations”. As such the CSP does not calculate an answer, it        merely searches and selects the best answer from a pool of        predetermined solutions, or to put it another way, the CSP is        merely a search mechanism arranged to locate a solution from the        predetermined pool of answers within the CSP (this approach is        no different to, and suffers from the same limitations, as other        known systems);    -   2. The pool of solutions defined as “Domains” do not comprise        the total possible number of possible solutions as they are        related to a selected fixed number of tables. Specifically, they        are related to the number of tables that are to be set within a        restaurant. As such, all tables and table combinations can only        be determined form a fixed number of tables within the        restaurant. The CSP has no ability to consider additional tables        or remove tables from a restaurant's standard floor plan to        offer a truly optimised solution (this approach is no different        to, and suffers from the same limitations, as known systems);    -   3. The optimisation of the CSP does not take into account any        relationship established with the floor space within the        restaurant, and hence, the optimisation of that floor space        (this approach is no different to, and suffers from the same        limitations, as the known systems);    -   4. The determination of the pool of solutions (Domains)        comprising the “tables and Table combinations” does not        eliminate the need of a Restaurant Manager. Further, the skill        of the Restaurant Manager would be required on an on-going basis        should there be any changes to the size of the tables, the way        the tables were being set up, the quantity of tables etc. (this        approach is no different to, and suffers from the same        limitations, as known systems);    -   5. With the determination of the pool of solutions (Domains)        comprising the “tables and table combinations” the CSP does not        offer any checks and balances to ensure that all appropriate        solutions have been included within the CSP to ensure that any        selected solution is in fact an appropriate solution. At best        the CSP can only offer the best solution from the list of        inputted solutions (this approach is no different to, and        suffers from the same limitations, as known systems);    -   6. As the CSP is manually defined and inputted it is an        expensive exercise that has to be tailor made for each        individual restaurant. In other words, each implementation is        expensive to maintain and to reprogram if the restaurant makes        changes to its number tables, size of tables or table        combinations, making the resultant product too expensive and        inflexible for most restaurants;    -   7. Any changes to tables etc. also require significant manual        time and analysis to determine new table combinations and the        other inputs to the CSP;    -   8. The constraint information included in a CSP is only a small        subset and a very elementary and simplified representation of        all the constraint information that a Restaurant Manager should        take into account in the allocation of a booking. For example,        the CSP does not refer to a CRM (Customer Relationship        Management) database to understand the importance and priority        of customers or to know what table to allocate specific        customers to, such as their favourite table, or a window table,        or a quiet table. As such, the CSP solution can never        approximate the level of personalisation provided by that of the        Restaurant Manager (this approach is no different to, and        suffers from the same limitations, known solutions);    -   9. The CSP cannot offer a specific table to a customer during        the booking process or guarantee a specific table to an        individual booking request; and    -   10. The CSP is conceptually (and practically) a complete “mini        universe” and once the subset of real world constraints and        outcomes (table and table combination) are set up within this        high level mathematical equation there is no simple interface        that allows a user to amend the mathematically derived        constraints. Further, even if a user interface were to be        provided the CSP still requires mathematical experts to        re-calibrate the resultant equation and no checks and balances        exists to prove that the subset that has been created is a        complete subset (this approach is no different to, and suffers        from the same limitations, as known systems).

t) In Using Pre-Defined Solutions of “Tables” and “Table Combinations”and the System Cannot Offer Optimisation

The system of Vidotto is based on the ability of a restaurant to“optimise” bookings through a restaurants ability to search and find asolution from the pool of tables and table combinations when allocatingbookings.

Vidotto's acknowledges that his system searches for a solution. In thisregard, Vidotto at page 78 states:

-   -   “We present a study concerning the design of search algorithms,        again, finalised to produce a more efficient search. We conclude        by showing the benefit achieved on both representation and        search algorithms from comparing the solution we finally        achieved to the original, and others recommended by literature”        [underlining added]

Vidotto, at page 227, in providing suggestions for future work thatcould be undertaken to build upon his system, states:

-   -   “In this thesis, we have modelled table management as a        constraint satisfaction problem. In particular we have developed        a search approach based on multiple heuristics and time slicing,        which we have demonstrated improves search efficiency and        robustness for solving the table management problem compared to        other recommended approaches.” [underlining added]

Tables and table combinations are critical to the functioning of theVidotto system so that a search for the solution can be undertaken.Further, the concept of “table combinations” does not offer afundamentally better solution to the booking allocation problem.

In summary, any system that does not allow additional tables to bebrought into a restaurant or tables to be removed from a restaurantcannot optimise a space within a restaurant. Vidotto's proposed solutiontherefore contains the same fundamental technical problems found in theprevious practical art, the only difference being that the solutionprovided utilises a different system for searching for a table, whichonly results in the creation of a system that is not practical inimplementation.

u) Use of Constraint Programming is Not Practical

Another major drawback in the application of Vidotto's solution is therequirement whereby the restaurant manager, a mathematician, and acomputer programmer are required to manually develop, define andmaintain the system.

v) Use of Scheduling Programming in Conjunction with ConstraintProgramming is Computationally Inefficient

While constraint programming represents the core of Vidotto's work,Vidotto did not use constraint programming in isolation as constraintprogramming cannot account for the dimension of time. The dimension oftime is important to a restaurant as a booking request utilises a tablefor a period of time, after which the table is vacated and becomesreusable. Time is therefore an integral component of any efficientbooking process. Vidotto introduces the scheduling aspect to account fortime in his cited art on page 61 where he states:

-   -   “Scheduling jobs with fixed start and end times (SFSE) is a        subclass of scheduling, and represents the base for our        scheduling model for the restaurant table allocation problem”        [underlining added]

Vidotto then builds upon his base scheduling model of his cited art onpage 78 where he states:

-   -   “In the next section we represent table management as a        scheduling problem, with tables as resources and parties and        tasks with fixed start and end times. We then introduce an        initial (basic) CSP representation of the static problem. We        extend the original representation with some pre-solving checks        and additional constraints designed for improving the efficiency        through enforcing extra constraint propagation. We present a        study concerning the design of search algorithms, again,        finalised to produce a more efficient search. We conclude by        showing the benefit achieved on both representation and search        algorithms from comparing the solution we finally achieved to        the original, and others recommended by literature” [underlining        added]

Vidotto, then summarises the contribution of his findings on page 233where he states:

-   -   “Restaurant table management is a complex and dynamic problem:        restaurants must manage reservations and unexpected events in        real-time, making good use of resources, and providing good        service to customers. In this dissertation, we represented the        dynamic table management problem as a sequence of static        problems linked by changes. We modelled the underlying static        problem as a sequence of static problems linked by changes. We        modelled the underlying static problem as a subclass of        scheduling with fixed start and end times.” [underlining added]

It was through this process that Vidotto was able to incorporate timewithin this work and then display the results on a Gantt. In ouropinion, this process is disconnected as the relationship between thescheduling program and software and the imbedded or sub-set constraintprogram do not have a natural or common denominator for this process tomathematically or logically flow. The disconnection of spatial conceptsand time in the cited art of Vidotto are highlighted by the unusablelayout and format of the information he presents in FIG. 7.4 on page210. Specifically, he refers to FIG. 7.4 where he states:

-   -   “User interface, displaying a table map of the new seating plan        with party”[underlining added]

Use of the term “table map” in this context is completely misleading andthe information within FIG. 7.4 is of little use to a restaurant manageras:

-   -   1. In common usage, the term “table map” is synonymous with the        words “table plan”. FIG. 7.4 is not a “table plan” of the        restaurant or a representation of the layout of the tables        within the restaurant floor plan.    -   2. FIG. 7.4 merely contains a representation of various boxes        that are not laid out in any easily identifiable pattern, or a        representation of the layout of the tables within the        restaurant.    -   3. The information contained within each of the boxes is very        difficult to decipher and without reference to the column of        information to the left is meaningless to a restaurant manager        during a high pressure service period. For example, the booking        at 6:00 pm for Buckley can only be found by the manual search of        each of the boxes until you find that the name Buckley was        entered into each of the boxes representing Tables 21, 22, and        23 which is not very intuitive.

w) Use of Constraint Programming is Computationally Inefficient and DoesNot Offer a Practical Solution

Vidotto acknowledged that his work was inherently computationallyinefficient and that further work needed to be done to improve thecomputational efficiency of his proposed solution. On page 227 of histhesis Vidotto discusses areas where he believes more work could be doneto further develop his work:

-   -   “In this thesis, we have modelled table management as a        constraint satisfaction problem. In particular we have developed        a search approach based on multiple heuristics and time slicing,        which we have demonstrated improves search efficiency and        robustness for solving the table management problem compared to        other recommended approaches.”    -   “The different ordering heuristics and the different time limits        were not tuned, but were generated by inspection of the problem        characteristics, so better performance should be achievable.”    -   “Future work should then focus on optimising the set of        heuristics, the order heuristics are selected within the same        set, and the sequence of time limits.”    -   “Future work should investigate whether, when, and to what        extent, savings in search outweigh the overhead of caching”        [Underlining added]

x) Dynamic Estimating (Bossert, 2009)

Bossert in his 2009 patent application stated his objective and purposeat paragraph [0008] in a similar fashion to Vidotto where he states:

-   -   “A need therefore exists in the art for an improved manner of        handling reservation requests for restaurant capacities and        similar resources that more fully utilizes resource        configurability to increase yield and revenue.” [Underlining        added]

Bossert acknowledged the existence of constraint programming and thesolution for his capacity problem within a restaurant at paragraph[0047] he states:

-   -   “Methods to perform the calculations of the capacity module 60        exist in the prior art. For example, mathematical and logical        constraints can be used to describe the seating capacity of a        restaurant whose tables may be reconfigured and constraint        programming solution procedures can determine or at least        estimate whether the restaurant has sufficient capacity to        accept a set of table reservation requests”. [Underlining added]

While Bossert acknowledged the existence of “constraint programming”within the prior art Bossert also shared Vidotto's concerns theimpractical computational times required by a constraint program in itssearch for a solution, at paragraph [0054] Bossert states:

-   -   “While the above recursion is amenable to computer        implementation, those of ordinary skill in the art will        appreciate that exact solution may be computationally tractable        for only small restaurants.”    -   “In particular, the state space may grow very quickly with        restaurant size, and the formulation may exhibit the so-called        curse of dimensionality of dynamic programming methods.”    -   “As such, the combinatorial nature of the state space may render        impractically burdensome the memory or solution time required to        evaluate the seats-to-go functions jk as called for by the        dynamic programming recursion.” [underlining added]

To overcome the computational time problems, Bossert proposed an“Approximate Dynamic Programming Solution Approach”. Specifically, atparagraph [0055] Bossert states:

-   -   “To achieve more practical computational times and reduce memory        requirements, disclosed hereinbelow is an Approximate Dynamic        Programming (ADP) approach based on Monte Carlo Simulation and        approximation of the seats-to-go functions”.[underlining added]

Bossert discloses an approach that was further removed from the actualmanner in which a restaurant allocates tables and resources, and onethat is more dependent on estimations, approximations and mathematicalcomplexities, in attempting to overcome the mathematical complexitiesand definitional problems of the chosen method of “constraintprogramming” as a technique for solving the allocation problem.

Despite their best efforts to find a solution to the impracticalcomputational times required by constraint programming both Vidotto andBossert have failed as their solutions are yet to be adopted or appliedin industry.

Bossert, by adding additional heuristics and approximations as anextension to Vidotto's work, added additional prohibitive costs in thecreation of bespoke solutions for each restaurant (by virtue of eachrestaurant having a different number of tables and table combinationsand constraint information, means each restaurant requires a tailoredmathematical solution and formulas which is expensive to implement,change and/or modify). Secondly, any reliance or dependency on“approximations” or “estimations”, or other approaches that requireguesswork cannot be said to offer finite solutions which ultimatelyresult in a more efficient allocation.

Bossert lists numerous possible constraints and variables that can betaken into consideration, but fails to provide any detail as to how suchvariables could be practically incorporated into a constraintprogramming model. In fact, the disclosure in Bossert is limited togeneric statements concerning the use of approximate dynamic programmingtechniques and estimations which remain as abstract ideas, with noenabling disclosure of how such ideas could be implemented in anyresultant software application. As such, Bossert's disclosure, likeVidotto's, remains without application but unlike Vidotto's work whichprovided enabling disclosure (despite not being practical) Bossert'sdisclosures within his patent application are best described as mere“paper anticipations” of various desirable features, but with noreduction to practice.

y) Yield Management (Bossert, 2009)

Yield management, by definition, is the strategic control of inventoryto sell the right product to the right customer at the right time forthe right price.

Bossert fails to address yield management in any meaningful manner,particularly as his use of yield management has not been used todetermine the product, the timing, the price and then used thatinformation to determine how many of the restaurants tables, and whichtables or spaces within the restaurant would be made available for eachof the different products offered such that the capacity to be madeavailable was known prior to the booking request being received.

For yield management to be undertaken correctly it is necessary toaddress at least two fundamental issues:

-   -   1. Firstly, the algorithm, equation or process must be able to        discriminate between customers through a process of either        charging customers a different price for the same goods or        services depending on some other factor (e.g. the time when the        product is bought or the service is carried out), or charging        customers a different price for different services or products        (e.g. only offering a three course meal at a peak booking times        while permitting the sale of a one course meal at an off-peak        time). As a simple example, Bossert provides no solution as to        how to discriminate between a window table which one could        potentially charge a higher price to a table next to the toilet        or a table next to the kitchen door. Similarly, the methodology        proposed by Bossert is not able to take into account any        variables, such as how tables could be treated differently at        different time periods or how different conditions could be        imposed to control the tables or capacity being offered. For        example, how can a restaurant limit bookings for people only        wanting to have one course at a peak time of say 7:30 pm which        may mean that the restaurant cannot use the table before that        time and after that time when the preference should be to only        offer a three course menu for bookings to be accepted at 7:30        pm?    -   2. Secondly, yield management is essentially the application of        a defined algorithm or mathematical formula to the control of        inventory. As such, a yield management module in the context of        a software solution must be able to specifically control and        release inventory. Bossert fails to provide a yield management        solution that is capable of controlling the release of        inventory, as the disclosure, at FIG. 3 describes a process        where a capacity calculation module (“60”) firstly determines        capacity (using constraint programming and its inherent        limitations) and only then does the proposed yield management        calculation module (“70”) accept or reject a reservation        request. By taking this approach, Bossert is essentially        “putting the cart before the horse”.

The yield management disclosure of Bossert has no practical utility, noris it an enabling disclosure, as it does not adhere to yield managementprinciples, it does not properly apply yield management principles andit does not describe a workable solution. It is, at best, a mere “paperanticipation” for a set of ideas, not a workable embodiment thatutilises yield management terminology.

SUMMARY

In a first aspect, the invention provides a computing system foroptimising and allocating bookings within a space for a defined periodof time in a venue, comprising an optimisation and allocation module incommunication with a processor and arranged to receive the at least onerequest and communicate with a database to determine whether otherrequests for spaces have been made by other users, and if so, utilisethe processor to retrieve information regarding the other requests forspaces and combine the at least one request with other requests to forma pool of requests, retrieve constraint information regarding the venueincluding information regarding the size of the venue and the size andquantity of available furniture that may be allocated to the space inthe venue, and in a structured way iteratively allocate all requestsfrom the pool of requests utilising the restraint information to producean optimised and/or prioritised allocation instruction set, wherein theoptimised and/or prioritised allocation instruction set saved in thedatabase and provided by a space allocation user interface to one ormore users associated with the venue.

In one embodiment, to provide a computing system and a user interface toat least one remote user to input the restaurant's floor plans to scaleto be stored in the data base.

In one embodiment, to provide a computing system and a user interface toat least one remote user to input and divide the restaurant's scaledplans into spaces, subspaces and sections and maintain all informationto scale with that information to be stored in the data base

In one embodiment, the venue, space, subspaces and sections can bedivided into different classes and to create a ranking system for eachclass and in one example provide different menus, service, and orofferings to each different class.

In one embodiment, to provide a computing system and a user interface toat least one remote user to create tables, chairs and other furniture toscale within the scaled floor plans, areas, subareas and sections andfor that information to be stored within the data base.

In one embodiment, the system further comprises a sub-ranking of eachtable within each space, subspace, section and class wherein the rankingand sub-ranking is utilised as part of the algorithm to prioritise theallocation bookings and ensure the restaurants loyal customers orspecial persons are given better tables and seating.

In one embodiment, the user interface allows the at least one remoteuser to input into the table number generator their preferred tablenumber groupings for the generation of table numbers for tables.

In one embodiment, the user interface allow the at least one remote userto input into the position number generator information as to how theposition numbers are to be structured around a table allocated to aspace, subspace, section or class in the allocation of a booking.

In one embodiment the user interface is arranged to allow at least oneremote user to input information relating one or more objects offurniture. For example, the system may allow the user to provide tableset-up details, such as which types of tables and table tops areinterchangeable, or which chairs may be paired with particular types oftables. In this manner, the algorithm is provided with increasedflexibility in the manner in which different items of furniture may bepaired and/or substituted.

In one embodiment, the user interface allows at least one remote user todefine the quantum and sizes of the tables and chairs allocated to thedifferent spaces, subspaces and sections on the floor plan noting whichare fixed tables and chairs and, which are flexible tables and chairs,and which can be moved and reallocated as well as defining theadditional quantum and sizes of additional tables and chairs that can bebrought in as required to optimise the seating available on the scaledfloor plan which would vary in one example, based on the different sizesof bookings received.

In one embodiment, the user interface allows the at least one remoteuser to define the seating priority for bookings within the differentspaces, subspaces and sections.

In one embodiment, the user interface allows the at least one remoteuser to define the dimension of the gap required between tables fordifferent bookings by space, by subspace, by section, by class.

In one embodiment, the user interface allows the at least one remoteuser to input into the data base different seating periods that areallowed during a particular service. For example, breakfast, lunch ordinner on any particular day. This feature allows the restaurant to haveflexible seating periods of different durations that can overlap. Inturn, the ability to set up multiple seating periods is utilised by theiteration process of the algorithm, ensuring that an existing booking onan earlier seating has been given the time allocated to it based on itschoice of menu and other constraints plus allowance has been made forthe time to reset the table before a further booking can be made on thattable for a later seating booking. To ensure time is better managed andoptimised in the allocation of bookings to a space, table or tablecombination

In one embodiment, the data base includes different menus, differentnumber of courses per menu, different group sizes and they are allocateddifferent booking times and duration periods of time that would beoffered to a booking request, wherein, this information would beutilised as part of the algorithm to allocate bookings and ensurebooking times accepted did not overlap or conflict.

In one embodiment, the data base includes the different time that wouldbe required to prepare and re-set tables for re-use by day and by timeas part of the algorithm to allocate bookings and ensure booking timesaccepted did not overlap or conflict due to the requirement to resettables.

In one embodiment, the database includes sub-space constraintinformation regarding sub-spaces with the space available within thevenue, whereby the iterative and structured allocation of requests foreach sub-space, independent of other sub-spaces, to optimise and/orprioritise the allocation of space and time within each sub-space.

In one embodiment, the database includes section constraint informationregarding sections within each of the spaces and sub-spaces availablewithin the venue, whereby the iterative allocation of requests occursfor each section, independent or in conjunction with other sections, tooptimise and/or prioritise the allocation of space and time within eachsection.

In one embodiment, the data base includes constraint information thatinformation that define spaces and subspaces to include objectsincluding furniture that are fixed and cannot change during the bookingallocation process.

In one embodiment, the data base includes constraint information thatdefine sections within spaces and subspaces as including objectsincluding furniture that are flexible and can be rearranged added to orremoved during the booking allocation process.

In one embodiment, the data base includes constraint information wherebydifferent sections comprising object areas are classified differently.

In one embodiment, the data base includes constraint information wherebydifferent sections classifications comprise different constraints anddifferent outcomes during the booking allocation process.

In one embodiment, the different constraints for the different sectioncategories can include different table size tables with different chairsand different gaps between tables different permitted maximum tablesizes when tables are joined which could be less than the maximumphysically possible within a section.

In one embodiment, the different constraints for the different sectioncategories can include details of which tables are interchangeable withwhich tables, the patterns of table allocations which can be created andmay include a process where a round table is placed between created orallocated rectangular tables.

In one embodiment, the different constraints for the different sectioncategories and fixed tables can include which sections and or fixedtables can be utilised to cater for larger bookings. Where suchinformation is not provided, in one embodiment, all larger bookings thatdo not fit within one space, subspace, section or class will beallocated to sections and fixed tables that utilise the smallest amountof continuous floor space.

In one embodiment, the different constraints for the different sectionscan include the dividing of one section into one or more subsectionswith different constraints for each subsection.

The database may include constraint information regarding multiplespaces, whereby the iterative allocation of requests occurs for each oneof the multiple spaces, independent of other spaces, to optimise and/orprioritise the allocation of space and time within each space.

In one embodiment, the database includes object constraint informationregarding at least one object including but not limited to a table,chair and/or stool arranged to be allocated to a space, whereby theiterative allocation of requests for spaces includes utilising theobject constraint information to optimise and/or prioritise theallocation of a space, a sub-space and/or a section in the venue.

In one embodiment, the object constraint information is informationregarding at least one of the dimensions of the spaces, dimensions ofsubspaces, the dimensions of sections and the dimensions of one or moreitems of furniture.

Firstly, with regards to tables our claimed invention uses its spatialknowledge of the restaurant premises to create tables as required by thebookings received. As such, it can add or remove tables from arestaurant's standard floor plan. From that perspective our firstdimension can be said to be the restaurant floor plan (length and width)properly dimensioned and to scale with all objects in correctrelativity. Then secondly, time is used as the other dimension to turnour two dimensional floor plan from a single flat plane to a volumetriccube by introducing time as the other axis.

The claimed invention utilises, in contrast, a decision tree logicstructure which seeks to find a “pathway” to a solution that it createsthat not only optimises the allocation of bookings to tables, but alsoseeks to optimise the placement of tables. In effect, the claimedinvention optimises the number and placement of tables for the number ofbookings, rather than simply trying to allocate bookings to apredetermined fixed number of tables and table combinations which haveno spatial relationship to each other.

In addition, the decision tree is dynamic, in that the decision treedoes not merely provide a series of “yes/no” gates, but rather, if as aconsequence of the constraint information, a sub-optimal solution isprovided, the claimed invention is able to iterate with variedconditions, in an attempt to create an optimised solution for therestaurant and the client

Fourthly, as a corollary, the claimed invention does not require theinput of tables and table combinations, as the starting premise for theclaimed invention is not a predetermined number and/or layout of tablesand table combinations. Rather, the claimed invention, upon receivingrelevant constraint information, is tasked with not only allocating abooking to a table, but also allocating a table to an appropriatelocation in the space to achieve both qualitative and quantitativeoutcomes:

-   -   1. The claimed invention provides dynamic allocation of        bookings, which may be optimised for a mixture of both        quantitative and qualitative outcomes. This is achieved by the        use of “spatial awareness” algorithms. Examples of the        quantitative and qualitative outcomes include:    -   Quantitative Outcomes include:    -   a) Optimising one restaurant space before another restaurant        space;    -   b) Optimising the whole restaurant and different spaces at the        same time; and    -   c) Allocation of a booking to a specific table.    -   ii. Qualitative Outcomes include:    -   a) Allocating bookings to the “best” tables;    -   b) Leaving an empty table between bookings when the restaurant        is not full to give bookings greater privacy; and    -   c) The allocation of a SVIP to their preferred table.    -   2. Moreover, as the algorithm has knowledge of the space and the        furniture within the space, bookings can be allocated in a        completely autonomous manner. In the description, it is clearly        shown the underlying feature of “spatial awareness” allows        completely autonomous restaurant management system from the time        of the online restaurant booking request until the time a person        leaves the restaurant other than the physical aspects of cooking        the food, delivering the food and beverages to the table and        cleaning and resetting a table.    -   3. The restaurant may also selectively choose the level of        automation they wish to use within their restaurant. Hence the        claimed invention can cater for anything from a casual café to a        three Michelin star restaurant so no limitations or barriers        exist in its industry applicability.    -   4. As the claimed invention has knowledge of the space, the        invention can be utilised to optimise for almost any relevant        desired outcome, whether it be revenue optimisation, cost        minimisation or maximisation of the customer experience.

In one embodiment, the optimisation and/or prioritisation moduleiteratively allocates bookings to a table or a group of tables utilisingconstraint information arranged to create a particular ambiance withinthe space. The ambiance constraints in one embodiment include analgorithm that includes any one or more of the following parameters:

-   -   1. The allocation of bookings to the best available tables when        the restaurant or a space, sub-space, section or class is not        forecasted or predicted to be required or full, taking into        account potential late bookings and walk-in customers;    -   2. The upgrade of bookings to better available tables where the        better tables are not forecasted or predicted including late        bookings and walk-in to be required;    -   3. The allocation of bookings based on a customer's CRM history        or social media profile; and/or    -   4. The allocation of bookings based on a First In Best Seat        (“FIBS”) system on the basis that the earliest request received        should receive priority, as it is likely that such a booking may        represent a significant special occasion like a wedding        anniversary, special birthday or occasion as compared to a last        minute booking where expectations could be less or would be less        on the basis that it is a last minute booking.

In one embodiment, the optimisation or prioritisation is undertakenutilising an iterative process including at least one of the followingalgorithmic steps: firstly allocating the request for the most number ofseats or metric from the pooled group of requests for the first definedseating period or subset period which is less than the entire period ofan individual service being allocated to a space that represents thesmallest best fit space within the smallest fixed seating area, section,subspace or space within a venue; secondly allocating the second largestbooking request from the pooled group of requests for the same definedseating period or subset period being allocated to a space thatrepresents the smallest best space within the available smallest fixedseating area, section, subspace or space within a venue after takinginto account previously allocated bookings; and continued allocation ofall remaining bookings until all booking requests have been allocatedfor all seating periods or subset periods, or in the event that abooking cannot be allocated, the last received booking being placed on awaitlist and/or the user being given a different availability for theirbooking.

In one embodiment of the system the application of the followingmethodology:

-   -   a. allocating the received booking request to the requested        table;    -   b. allocating the received booking request to the requested        table by firstly identifying one or more requestors associated        with the booking request, and using the identity of the one or        more requestors to retrieve constraint information including a        requestor ranking relative to other requestors, whereby the        booking request is allocated based on the requestor ranking;    -   c. where a requested table is already allocated to a previous        booking request, determining the identity of the one or more        requestors associated with the booking request and using the        identity of the one or more requestors to retrieve constraint        information including a requestor ranking relative to the        previous booking requestors, and if the ranking of the requestor        is higher than the ranking of the previous booking requestor,        reallocating the at least one previously allocated booking        request to a different table to allow the received booking        request to be allocated to the requested booked table;    -   d. upon requiring a reallocation of at least one booking to        accommodate a received booking request, reallocating the at        least one previously allocated booking request by allocating the        booking request of the largest size first and reallocating all        other booking requests in descending order of size;    -   e. upon requiring a reallocation of at least one booking to        accommodate a received booking request, determining a booking        size metric of the received booking and each of the allocated        bookings by calculating a size metric which utilises the number        of persons that comprise the booking request and the service        time duration for the booking request as inputs, and utilising        the size metric to reallocate all bookings in order from the        largest size metric booking to the smallest size metric booking;    -   f. determining a difficulty metric utilising the size metric and        a peak period seating time value to determine a difficulty        measure, the difficulty measure representing a theoretical        measure of the relative difficulty in allocating the booking        request, whereby booking requests are ranked from most difficult        to least difficult and allocated in descending order from most        difficult to least difficult;    -   g. determining sub-service periods within a service period, and        for all booking requests that fall within the service period,        firstly allocating all booking requests that fall across one or        more sub-service periods in order of descending size, and        subsequently allocating all booking requests that do not fall        across the one or more sub-service periods in order of        descending size;    -   h. utilising constraint information to determine a difficulty        measure, the difficulty measure being representative of the        relative difficulty of allocating a booking request, whereby        bookings are allocated in descending order of difficulty;    -   i. reallocating at least one previously allocated booking        request to optimise the number of bookings within each of the        one or more spaces;    -   j. reallocating at least one previously allocated booking        whereby bookings of identical or similar size are clustered, in        both physical proximity and chronological proximity;    -   k. reallocating at least one previously allocated booking        whereby the total time that the each table or table combination        remains unused between bookings during a single service period        is minimised;    -   l. reallocating at least one previously allocated booking to        cluster bookings such that physically adjacent tables have        similar start times;    -   m. reallocating at least one previously allocated booking such        that physically adjacent tables have similar finish times;    -   n. reallocating at least one previously allocated booking so        that smaller size bookings are physically clustered adjacent to        larger size bookings;    -   o. Reallocating at least one previously allocated booking such        that a previously joined table for an earlier booking in a        service period is reutilised for a later booking in the service        period;    -   p. reallocating at least one previously allocated booking such        that the at least one booking is allocated in a manner where a        minimal number of tables are joined or split to allocate the        booking;    -   q. reallocating at least one previously allocated booking such        that the total of bookings within a service period are arranged        in a manner that requires the least possible number of table        movements during the service period;    -   r. allocating at least one potentially conflicting booking to        the smallest fitting table irrespective of availability, and        where a conflicting booking is generated, reallocating the        previously allocated booking as a result of the newly created        conflicting allocation;    -   s. reallocating at least one previously allocated booking        whereby an empty table is retained between one or more booked        table;    -   t. utilising constraint information to reallocate all bookings        from the highest ranked available table in a descending order of        rank;    -   u. reallocating at least one previously allocated booking        whereby the ranking of the booking requestor determines the        table allocated;    -   v. reallocating at least one previously allocated booking        utilising one or more qualitative constraints derived from        information associated with the booking requestor including but        not limited to a stated occasion associated with the booking, a        menu or courses selected by the requestor, the courses selected        by the requestor, ancillary products selected by the requestor        and the date of the booking; and    -   w. reallocating all bookings to one or more different table        solution sets to determine whether at least one of the one or        more different table solution sets results in a more optimal        outcome, and if so, selecting the at least one of the one or        more different table solution sets that results in the more        optimal outcome.

In one embodiment of the system the ranking of all tables and tablecombinations available for booking requests from best to worst.

In one embodiment of the system the relative location of each table andtable combination.

In one embodiment of the system wherein the algorithm can determine ifadditional furniture can be brought in or removed from the availablelist of tables and table combinations if such action will result in amore optimised outcome.

In one embodiment of the system offering different menus and pricing fordifferent booking intervals, services, dates and dates.

In one embodiment, the algorithm utilised for bookings made prior to aservice is different to the algorithm used while a service is in processwhereby no new additional tables are brought into an area, subarea,section or class.

In one embodiment, the optimisation module may allocate a booking to atable, and entire section, subspace, space or any combination thereof orthe entire venue such that all booking requests can be undertakenautonomously irrespective of the size of the booking or the specificrequirements of the user making the booking.

In one embodiment, the optimisation and prioritisation model is linkedto a CRM and, or third party websites and capable of differentiatingbetween booking requests where there are identical or similar bookingsto allocate the higher ranked table to the higher ranked, more regularcustomers, or potentially more beneficial customers to the restaurantutilising information from at least one of internal or third partydatabases of information, wherein the identity of the customer makingthe booking is utilised in conjunction with the database information.The CRM may include any relevant information, such as:

-   -   1. Customer membership levels;    -   2. Customer rankings within each membership level;    -   3. Customer priority seating levels (“VIP” and “SVIP”);    -   4. Customer seating preferences including, space, tables,        chairs;    -   5. Customer constraint preferences as used in the various        algorithms;    -   6. Customer information including individual item selections        from previous visits over and above any booking information for        the table through the use of position numbers with the booking;        and/or    -   7. Waiter and staff inputted information concerning details and        preferences of the customer with reference to the booking        allocation algorithm.

In one embodiment, all locations, sections, subspaces and spaces areallocated a dynamic identifier such that all tables are sequentiallynumbered in a consistent manner irrespective of the relativereconfiguration of the tables as more bookings are taken so their usageor usage of the area can be monitored and compile an area or tablepreference rating which can be used for the dynamic pricing of tables.

In one embodiment, the constraint information can determine and makeavailable a plurality of booking times and capacities such that a usermay select specific tables, locations and/or seating arrangements fromthe available tables, locations and/or seating arrangements with orwithout the requirement of an additional payment.

In one embodiment, the constraint information is arranged to vary theavailable menu and courses to a customer dependent on group size, or theday or time of an available booking, in a manner which optimisesavailable resources within a restaurant.

In one embodiment, the constraint information is arranged to vary theparty sizes that it will accept at different times, such thatinefficient booking sizes such as 1, 3 or 5 which result in tables withunutilised seats being eliminated from peak restaurant booking anddemand times.

In one embodiment, a user can select any one of a preferred table,selecting booking time, time duration at the table and payment of afurther amount.

In one embodiment, the computing system is arranged to communicate, viaa communications network, with supplier servers (the suppliers beingarranged to provide third party services), wherein a request to utilisea third party service received from a user is autonomously relayed tothe third party site. For example, the database of the embodiment mayinclude information regarding florists, chocolate shops, guitarists,magicians and entertainers, to provide a listing of the additionalservices that a diner may request through their booking in addition toany ad hoc requests made by the diner upon booking.

In one embodiment, a customer can create a tailored and personaliseddining experience where they can select any number of personalisedservices such as, their personal waiter, a specific flower arrangementon the table or a bunch of flowers for their guest, a bottle ofchampagne next to their table to be opened on their arrival, a specificfood and beverage menu or specific food and beverage items including theprovision of a specific vintage or rare bottle of wine, a guitarist orother entertainer during their meal or a present on departure toremember the evening, inviting guests, creating place cards andallocating guests to table position numbers.

In more detail, in the embodiment described above, the computing systemis arranged to manage and communicate bespoke and personalised diningexperience selections whereby the system automatically places orderswith suppliers, confirmations, compiles run sheets and information forthe restaurant's Head Chef and Restaurant Manager and Restaurant officestaff of the requirements and post the information on the restaurantsdiary, and issue invoices and receive payments.

In one embodiment, there is further provided a self-seating app orwidget showing the allocated table location within the restaurant floorplan, together with the table number and the position numbers andlocation of each individual guest including the ability to print namecards for use on the table.

In one embodiment, the optimisation or prioritisation algorithm utilisesthe processor to determine the revenue potential for a particularcombination of menu, group size and date/time of a booking, wherein thealgorithm dynamically varies the booking options offered to a customerto control the capacity offered to optimise revenue.

In one embodiment, the system is arranged to monitor the user requestfor any particular table, section, subspace, space, class or venue by atleast one of the date, service, time, occasion, group size, or otherrelevant parameter to determine the appropriateness of dynamic pricingchanges for the table, area, subarea, section or class or changes toother parts of the venue to increase efficiency.

In one embodiment, the system is arranged to utilise informationregarding the historical performance of one or more spaces, subspaces,sections or classes to improve the performance of one or more otherspaces, subspaces, sections or classes. In other words, the systemutilises an algorithm that utilises a number of types of informationrelevant to entire space and applies the information gained from onesection of the restaurant to better organise another area of therestaurant. In colloquial terms, the algorithm takes a “holistic”overview of the restaurant as a whole before optimising a space,subspace, section, or class.

In one embodiment, the system is arranged to execute a simulation usingestimated booking patterns or historical booking patterns to determinean optimal restaurant layout. The layout may include selecting the mostappropriate table sizes and furniture, quantities of different tablesizes and furniture to purchase, flexible seating areas versus fixedseating areas, different combinations of areas, subareas and sections,different classes to determine an optimised restaurant furniture layoutso as to assist in the management of the restaurant, the set-up of therestaurant or the financial projections and planning of the restaurant.

In one embodiment, the system may also optimise one or more constraints,the iterative allocation of bookings and/or defining of a venue intospaces, subspaces, sections, classes within the restaurant the offeringof different menus in different situations and at different times, theallocation of SVIP's to their preferred table and the rating of tables.Such an embodiment allows customers to select their preferred table,offering different amounts of time to different menus with differentcourses. In other words, the constraint aspect of the broader inventiveconcept may be combined with a static linear combinatorial priority listto provide a level of optimisation and automation, while not utilising adynamic table allocation algorithm.

In one embodiment, the user interface is arranged, in response torestraint information provided by the user, to provide additionalrestraint information to the user, wherein the system provides aninterface to allow the user to accept the additional restraintinformation or alter their request.

In one embodiment, the database includes menu constraint informationregarding menus available, the menu constraint being dependent on thetime period constraint information provided by the user, whereby thecomputing system provides a choice to the user to accept the additionalrestraint information or the user alters their request dependent on themenu constraint information.

In one embodiment, the user interface is arranged to permit a user tosearch for the availability for two different spaces in a venue, and ifavailability is found in both spaces to book and pay for both spacessimultaneously. For example, a booking could be made for two stools at 7pm at the bar for drinks and then a table for 2 at 7:30 pm in the maindining room for dinner.

In one embodiment, the user interface is arranged to permit the user tosearch two different venues for availability and if availability isfound at both venues the user books and pays for both venuessimultaneously. For example, one venue may be a theatre or show and theother venue is a restaurant.

In one embodiment, the optimised and/or prioritised allocationinstruction set is saved in the database and provided as a diagrammaticrepresentation within a detailed representation of the floor plan. In aspecific embodiment, any new or additional tables or furniture addedinto a space, subspace, section, class or venue are highlighted so thatthe restaurant manager may easily visualise and understand the type,quantum, and location of the additional furniture as compared to thestandard floor plan layout, number of tables and location.

The claimed invention defines a properly constructed “three dimensionalvolumetric relationship” using the floor plan (two dimensions) and time(as the third dimension). As such, there are no requirements to usescheduling software techniques to incorporate time within the claimedinvention.

In one embodiment, the optimised and/or prioritised allocation set savedin the data base and provided as a diagrammatic representation within adetailed representation of the floor plan changes dynamically over time,such that the representation of the table allocation is layered in timewith a notation as to how many times each table will be used duringservice. In other words, the floor plan displayed on the user interfaceis a true “live” representation of the table plan at any point in timeduring a service with the representation of the tables being rearrangedwith the correct table numbers and gaps between tables. This featurealso allows restaurant staff or anyone looking at the floor plan toeasily identify the location of a table or easily understand how toreset and reposition tables.

In one embodiment, the system is arranged to autonomously communicate toa third party the requirement to provide additional furniture or otheritems required for a service

In a second aspect, there is provided a computer enabled method foroptimising the use of space in a venue, comprising the steps of:receiving at least one request to reserve a space or a table or a tablecombination within the venue from at least one remote user from anapplication residing on a remote device via the communications network,and retrieving other information and constraint information from thedata base such as, the menu or menus available for a particular day andtime as well as the time allocated for the menu and courses selected bygroup size and using that information to communicate with a user priorto accepting a request for a booking and then determining whether otherrequests for spaces have been made by other users, and if so, retrieveinformation regarding the other requests and information pertaining tothose requests for spaces, tables or table combinations and combine theat least one request with other requests to form a pool of requests, andother information pertaining to those requests retrieve constraintinformation regarding the venue, and iteratively allocate all requestsfrom the pool of requests utilising the restraint information to producean optimised space, tables or table combinations allocation instructionset, wherein the optimised prioritised and re-allocated space, tables ortable combinations allocation instruction set is provided to one or moreusers associated with the venue.

In one embodiment, a user interface is provided to at least one remoteuser to input into the data base the different menus that a restaurantwishes to make available by the different spaces, subspaces, classes andsections, on different days, for different meal periods and by the timesand group sizes they wish to make the menus available. For example, onlyoffering a one course menu option at 6 pm and requiring a person toaccept 3 course menu if they wish to dine at say a peak time like 7:30pm; or offering a more expensive menu for more premium seating; oroffering a cheaper price or cheaper menu for less premium seating forallocation to a space, subspace, section, class, table or tablecombination.

In one embodiment, the user interface is arranged to allow at least oneremote user to input into the data base the different duration timesthat will be allowed for a booking based on constraints such as, themenu selected, the number of courses selected, the size of the group,the occasion and the day and is also used to inform user of thiscondition as part of the accepted booking terms and conditions whereinthe user can accept these conditions or alter their request.

In one embodiment, there is provided a user interface to at least oneremote user to input into the database the different times required toreset a space, subspace, section, class, table, or table combination.This information may subsequently be reutilised to ensure thatturnaround times are efficiently managed.

In one embodiment, the user interface allows at least one remote user toinput into the data base the different seating periods that would beallowed during a defined period of service (such as dinner) on anyparticular day. This feature allows the restaurant to have not onlyfixed seating periods but also flexible seating periods of differentdurations that can overlap. The iteration process by the algorithm canbe undertaken multiple times, and can include iterating once for eachdefined seating period with the algorithm ensuring that an existingbooking on an earlier seating has been given the time allocated to itbased on its choice of menu and other constraints plus allowance hasbeen made for the time to reset the table before a further booking canbe made on that table for a later seating booking. In other words, timeis better managed and optimised in the allocation of bookings to aspace, table or table combination.

In one embodiment, there is provided an application residing on a remotedevice arranged to access a data base that provides standard and specialmenus that are dynamically displayed depending on the availability ofthose menus during a particular time period and group size. The menuscan be referred to by users to see the menus available and the timesthat they will be available prior to making a booking or to select fromwhen pre-ordering or for ordering at the restaurant during a serviceperiod.

In one embodiment, the prioritisation algorithm varies the menu offeredto a customer dependent on at least one of group size, occasion, bookingtime, and the day of an available booking, in a manner that permits theoptimisation of revenue and efficiency within a restaurant in theallocation of bookings to spaces, subspaces, sections classes, tables ortable combinations.

In one embodiment, wherein the data base includes menu constraintinformation regarding menus available dependent on the time periodconstraint information provided by the user, whereby the user can selectto accept the additional restraint information or can alter theirrequest dependent on the menu constraint information.

In one embodiment, wherein the database includes menu constraintinformation regarding the number of courses provided in a menu based onat least one request.

In one embodiment, the data base includes time and/or date constraintinformation regarding at least one time and/or date that a space,sub-space, section, class, table or table combination available to beallocated wherein each time and/or date includes an indicator arrangedto allocate a relative rating to the time and/or date, wherein therating is utilised as a constraint condition. The constraint conditionmay require the user to pay a particular charge depending on the ratingassociated with the time and/or date.

In one embodiment, the user interface is arranged to allow the user tosearch a restaurant's availability not only by time as permitted by theprior art but also by:

-   1. Menu and menu courses including planned promotional special    menus;-   2. Group size;-   3. Tables to which a booking request can be guaranteed allocation;    and/or-   4. System generated specials to “back fill” awkward times, for    example, times between bookings and difficult to fill tables.

In one embodiment, the user interface is arranged to allow a user toselect at least one item from at least one menu to be consumed duringthe use of the space, sub-space, section, class, table, or tablecombination. Upon selecting the at least one menu item, the user may berequired to pay for the use of the space in advance of using the space.

In one embodiment, the user interface is configured to enable at leastone remote user to select a menu, and items on the menu for theallocated use of the space, sub-space, section, class, table or tablecombination and pay for at least a portion the use of the space inadvance of using the space.

In one embodiment, the user interface is configured to enable a firstremote user to invite a second remote user to interact with theinterface.

In one embodiment, the system is arranged to adjust the amount ofpre-payment received by a restaurant in a manner which maximises thecommitment by a user to a booking. This in turn minimises “no shows” andincreases upfront cash flow to a restaurant. The amount of pre-paymentrequired is determined by interrogating a database arranged to provideobject constraint information regarding one or more of the terms andconditions for a particular booking made available on a particular day,a particular service, a particular area, a particular class of seating,a table, a table combination, particular time, a particular menuselected, a particular number of courses, a particular number of guestsand/or a particular persons CRM ranking/rating, a user input modulearranged to receive information regarding the actual usable resources atany given time, wherein an optimisation module in communication with aprocessor receives the data, and the data is analysed to provide adynamic prepayment algorithm to determine the relative optimalprepayment that should be requested for a specific booking request.

In one embodiment, the system further includes a pre-payment decisiontree whereby each booking request is reviewed to determine ifpre-payment is required for the booking to be secured. As an example,some form of pre-payment may be required through the application of oneor more constraints for a particular booking request which could vary byday of the week, a particular event irrespective of the day, by peak andoff-peak times on a particular day, by menu selected, by coursesselected, by group size, by occasion and an algorithm determine the bestand most appropriate requirement for the booking to a space, subspace,section, class, table or table combination.

In another embodiment, there is provided a payment module arranged toprovide a pre-payment interface arranged to discriminate between bookingrequests wherein pre-payment obligations are tailored to the user'sbooking request. Such a module ensures that, where necessary, arequestor making a booking request has a greater commitment to ensuringthey turn up, minimising “no-shows” and increasing restaurant revenueand profitability in the allocation of a booking to a space, subspace,section, class, table or table combination.

In another embodiment, the system utilises information in the database,such as a person's CRM ranking, as a constraint to make a finaldetermination as to whether a person is required to meet the pre-paymentcriteria to secure the booking. Such a system provides greaterrecognition to loyal customers and assists in the process of displayingmutual trust and respect for loyal patronage.

In a third aspect, there is provided a computer optimisation systemincluding a system in accordance with the first aspect of the inventionwhich defines the capacity in the form of usage within a space, adatabase arranged to provide historical and live data regarding the useof the resources of a restaurant, an input module arranged to receiveinformation regarding the usable resources at any given time from thesystem according to the first aspect of the invention, an optimisationmodule in communication with a processor and arranged to receive the atleast one request and communicate with the database to receive thehistorical and live data and the usable resource data, wherein the datais analysed utilising a yield determination algorithm to determine, dataregarding the relative optimal use of the usable restaurant resourcesand provide relative optimal use data to the system in accordance withthe first aspect of the invention.

In another aspect associated with the third aspect, there is provided acomputing system for allocating one or more booking requests for theprovision of a service in a venue, the service including the allocationof a space within the venue and the provision of one or more productscomprising: a processor in communication with a product databaseincluding a plurality of products, each one of the plurality of productsbeing associated with a product capacity value, a user interfacearranged to interact with a booking requestor and the processor, theinterface being arranged to request product constraint informationregarding one or more constraints provided by the booking requestor,retrieve product capacity values from the database, and utilise theproduct capacity values and product constraint information to determineproduct availability, the interface being arranged to interact with therequestor and provide additional product information and supplementaryproduct information for the product requestor wherein the requestor mayone of agree to the additional constraints and request table capacityallocation for confirmation of the booking or reject the constraints andnot be allocated.

The system may use the qualified product information to determine tableavailability using an iterative allocation process in accordance withthe embodiments described herein.

The system may use the qualified product information to determine tableavailability using an optimised condition in accordance with theembodiments described herein.

The system may also use the qualified product information to determinetable availability by classifying tables into categories to aid in theallocation process.

In more detail, with reference to the aspect described above, theproduct can be the number of courses associated with a menu, a menuitem, a beverage, or a combination thereof.

A product has specific attributes and those attributes can include anassociation with a specific service period, booking time, bookingduration time, day of the week, date, group size and/or occasion.

The product may include or be associated with one or more services,including extended duration time, location within a venue, class oftables within a venue specific type of table, specific table within avenue, specific level of service.

The product can include third party items such as flowers,entertainment, etc.

A cost associated with the product may be set dynamically by time, groupsize, occasion, table location, specific table, payment of booking fees,additional services, discounts or promotional pricing.

In one embodiment, the yield management algorithms utilise capacitygenerated by space and time calculations. This is in contrast to knownyield management techniques which measure yield based on capacity asmeasured utilising tables and table combinations as discrete units ofcapacity.

In one embodiment, the dynamic pricing algorithm may use one or more oftime of day, date, space, subspace, section, class, peak, time of abooking, duration of a booking, menus with different courses, size ofbooking to control capacities offered for a particular space, subspace,section, class, menu, courses and size of booking

In one embodiment, the algorithm interrogates the data base to locateunbooked periods of time longer than the minimum time required toconsume a one course menu to match an appropriate menu or menu(s) to theperiods of time, wherein the system offers the located booking times andbooking durations to users at a discounted cost. This allows the systemto autonomously “backfill” unused time slots, which increases restaurantrevenue while minimising discounts offered for other non-constrainedbookings.

In one embodiment, the data base is interrogated to find periods of timethat contain short lead time unallocated space, sub-space, section,tables or chairs and offering such space at a discount in order tocreate and have a standby list of customers.

In one embodiment, the system is arranged to calculate and collectinformation concerning the duration times of customers and associatingthe duration times with relevant constraint information. The constraintinformation may include menu, menu courses, time of booking, day ofbooking, occasion, and/or group size. The collected information is usedto provide recommendations or autonomously adjust booking duration timesallowed for different areas, subareas, sections or classes at differenttimes, menus and courses offered.

In one embodiment, the seating allocation of a restaurant is analysed bycomparing the hypothetical actions which would have been taken by asystem in accordance with the invention, to actions taken by a manualintervention, to determine whether the autonomous action or the manualintervention provides or provided a more favourable outcome using acustomer's CRM or social media ranking.

In one embodiment, restaurant capacity is calculated as the product ofthe tables that are capable of incorporation into the space includingadditional tables as they would have been included by the autonomous useof the allocation algorithms and the number of chairs and the number ofhours that the restaurant is open for service. This hypotheticalcalculated capacity is utilised as a benchmark and used to compare toreal life performance (specifically against manual interventionsperformed by a member of staff) to evaluate whether the manualintervention produces a more desirable result. If so, the algorithmautonomously adjusts the algorithm and allocation process.

In one embodiment, restaurant utilisation is calculated as the productof the total number of guests that can be seated by the system andalgorithm including the allocation and use of additional tables and thenumber of hours that users were seated. In other words, the metric isthe product of the total chairs the system managed to incorporate intothe floor plan multiplied by the hours the restaurant was open for aservice or other defined period. This is a more useful metric as itrepresents a true utilisation value.

In one embodiment, the revenue yield is calculated as the product of theactual revenue received for a period divided by the revenue that couldhave been received if all items had been sold at their full recommendedretail plus the revenue at the full recommended retail price of anycomplimentary items. For this calculation to be undertaken a fullcomplete, itemised, detailed list of all products supplied to customersand other information contained in a restaurant point of sale system andother relevant information from other systems is integrated andrecorded.

In one embodiment, the efficiency of area space, subspace, section,class or restaurant is the product of the capacity utilisation and therevenue yield.

In one embodiment, an optimal capacity utilisation may be calculated byvarying defined fixed and flexible seating areas within the restaurantto determine an optimum ratio of fixed versus flexible seating areas. Inone embodiment, the system can recommend changes to areas, menus,courses, times, and/or group sizes to provide a more optimised solution.In the context of the embodiment described, optimum is defined accordingto goals set by the restaurant and by the inherent limitations of therestaurant, such as the table sizes and table types available within thefixed and flexible seating spaces, subspaces, sections, classes orwithin the restaurant.

In more detail, resource constraints such as desired customer servicestandards may be calculated by inputting wait staff to customer ratios,staff set-up times for different booking levels, bar staff to customerratios, food runner to staff ratios, reception staff to customer ratiosby booking times, kitchen to customer ratios based on menus offered fora service and/or if food is pre-ordered the input of more specifickitchen to staff ratios by space, subspace, section, or class while alsoconsidering additional personalised customer booking requests andrestaurant set-up requirements including allowing for late bookings andwalk-ins in combination with the timing of customer menus and arrivaltimes. This comprehensive input of data allows the system to providedetailed rosters which are created and communicated to staff.

In one embodiment, the user interface allows at least one remote user toinput into the data base information and constraints regarding aplurality of events that a restaurant may undertake, participate in orwhich may have an impact on the demand for the restaurant's services.The information and constraints provide input regarding the expectedimpact of such an event and may include, for example, the number ofinvited guests or the number of the people who may be expected to attendthe events. The event information and constraints are as an input by theforecasting algorithm to determine forecasted demand, which in turn isutilised to determine a set of constraints to apply to the capacityallocations, such as determining appropriate menus, courses, bookingtimes, booking durations, staffing and other resource requirements.

In one embodiment, additional information (such as forecasted weatherand known future events) is provided to the algorithm to predict futuredemand by space, subspace, section, class or for the restaurant. Thefuture predicted demand is used to adjust the options offered tocustomers. In other words, menus, booking times, booking durations, andthe relative probability of gaining additional revenue from the chargingof different fees such as from extending booking times, are calculated.In turn, the system may then allocate bookings and/or limit bookings.For example, if the probability of walk-in customers is high, sometables may be reserved for walk-in customers, who may then be charged ata premium. Alternatively, if the probability of walk-in customers islow, a discount may be applied to customers who book, in order toattract booking customers. That is, the system autonomously optimisesbooking constraints to optimise revenue for the restaurant.

In summary, previous utilisation patterns and other constraints may beutilised to forecast demand, revenue, and to autonomously adjust thecapacity and constraints provided by the system to a remote user.

In one embodiment, the associated constraint information includes anincentive, the incentive being communicated to the booking requestor.

In one embodiment, the allocation algorithm applies a differentialpricing model dependent on the venue constraint information and therequestor constraint information.

In one embodiment, the one or more potential booking allocations aredetermined by calculating the optimal revenue yield of a plurality ofpotential booking allocations and selecting one or more of the pluralityof potential booking allocations on the basis of a revenue yieldthreshold, wherein the selected one or more potential bookingallocations are communicated to the requestor.

In a fourth aspect, there is provided an autonomous, integrated bookingand management system.

For example, once flexible floor plans are calculated, the flexiblefloor plans are electronically transmitted to a Point Of Sale system(“POS”), which may include hand held devices. The electronictransmission of floor plans, which are updated in a contemporaneousmanner (including autonomous updating of table numbers) provide aseamless and autonomous continuous transfer of information for staff todisplay an exact representation of the floor plan at any point in timewith respect to aspects including table numbers table groupings andtable gaps.

In one embodiment, the transfer of information from the reservations andallocation system to other systems, such as, the labour and rostersystem, the food ordering and purchasing system and the kitchen printingsystem is autonomous.

In one embodiment, the reservations dairy is capable of autonomouslyprocessing any type of booking, including individual bookings andfunction bookings. This is achieved, at the user interface, by providingan integrated booking widget and/or booking app.

In one embodiment, the app or widget includes a self-seating functionwhich is capable of displaying and directing a user to a table bypresenting the user with an exact representation of the table and floorplan of the restaurant. This may be achieved by a combination of any oneor more types of information display, including a location map includinga restaurant floor plan, a table number, position numbers of individualguests and the ability to autonomously print name cards for use on thetable, or display electronic name cards in situations where electronicdisplays are available at the table.

In one embodiment, a user located in a restaurant reception area may begiven a device or use their own personal device to request a booking,order a meal, prepay and receive self-seating details. This provides anautonomous service, such that there is no requirement for the restaurantto provide staff to seat a person, allocate a table, take an orderand/or accept payment.

In one embodiment, individual customer information is tracked by tableposition number so that the restaurant CRM contains data specific to thecustomer. The collection of customer specific data allows for thetailoring of a customer's future visits.

In one embodiment, all walk-in customers are required to enteridentifying information into the booking system to allow the system toallocate tables. This allows the system to allocate the best availabletable to ensure the most efficient allocation of tables, ensure allcustomers to the restaurant are properly included in the CRM system forfuture use and not permit manual allocations.

In one embodiment, the reservations diary allows for multi-venues andmulti-time zones within a single diary. In other words, customer facingdiaries and internal diaries (which may operate in different manners)are automatically reconciled to avoid the need for any transfer ofinformation from one diary to another.

In more detail, there may be provided a multi calendar that permitsadditional user defined calendars to be created for reporting andmanagement purposes. The user defined calendars may have a differentstart and end date to the bookings calendar, a different number ofmonths and different start and end dates for each user defined month (orperiod), may commence on any day of the week, and has user definedreference points so that equivalent time periods in previously definedyears, months or weeks maybe reconciled against current or futuredefined years, months or weeks.

In one embodiment, the user defined calendar is used for the generationof business-centric performance, historical and forecasting reports.

In one embodiment, the performance module calculates and uses themeasures of available seat hours to measure capacity, actual seat hoursto measure usage, revenue yield to measure the actual revenue receivedagainst the revenue that could have been received had all items sold andcomplimentary items given been charged at their full recommended retailprice and efficiency as the product of capacity utilisation by therevenue yield.

In one embodiment, a home delivery diary is integrated into the systemand is arranged to receive on-line home delivery orders.

In one embodiment, a gift certificate system is integrated into thesystem and is arranged to issue gift certificates.

In one embodiment, a gift certificate module is provided, the paymentmodule is arranged to accept gift certificates as a form of pre-payment.The gift certificate may be utilised as a deposit, part payment or fullpayment fora booking.

In one embodiment, a kitchen interface is integrated, wherein orders areprovided to the kitchen for seated customers or home delivery ordersdirectly to the kitchen, wherein constraint information is provided toestimate cooking times and delivery times to thereby prioritise ordersand optionally communicate the estimated times to the restaurant managerand/or the customer.

In one embodiment, there is provided an autonomous, integratedrestaurant management system using the online booking system and thediary and data base as the core central system. The restaurantmanagement system may interface electronically with ancillary systems inorder to receive or provide information. Notwithstanding the requirementto source or provide data to other external systems, the restaurantmanagement system, in an embodiment, provides an integrated system byproviding the following functionality:

-   -   1. A CRM for the correct allocation and prioritisation of        bookings;    -   2. A database of evolving operational constraints for the        correct allocation and prioritisation of bookings;    -   3. A module to provide and redeem gift cards;    -   4. A POS system for the transfer of the dynamic and changing        floor plans and table numbers;    -   5. A POS system for transfer of any pre-orders or menu        selections;    -   6. A POS system and/or kitchen printer for the provision of        pre-orders directly to the kitchen;    -   7. A payment gateway for the collection and processing of        payments;    -   8. A home delivery ordering module for receiving and processing        home delivery orders, including the autonomous management of        kitchen priorities and workload;    -   9. An integrated booking module capable of receiving and        processing both individual and function bookings;    -   10. Integration with third party purchasing modules to        co-ordinate personalisation considerations for the ability to        provide dynamic reporting, forecasting and yield management        information to a requestor of the provision of dynamically        changing menus based on available times and resource constraints        for customers to review, pre-order, or order at the restaurant;        and/or    -   11. A self-seating capability which may be deployed to kiosks,        in-restaurant devices and/or user devices which provides a floor        plan showing the table allocated on a floor plan as it would be        on their arrival.

In one embodiment there is provided a user interface in the form of a“restaurant management page” in one embodiment or a “dashboard” arrangedto provide the restaurant manager with a summarised yet complete view ofall aspects and activities within the restaurant. The dashboard includesone or more pop-up screens to ensure that the user does not have toleave the main control cockpit screen. Further, the cockpit includes anemail display, an urgent message display, a home delivery summarydisplay, a walk-in summary display, individual booking run sheetdisplay, function run sheet display, a dynamic and current floor planand a reversible Gantt chart to easily highlight available tables,multiple area bookings, gift cards, floor plan or area selections, a CRMlink for bookings, a Restaurant Butler personalised details display,links to a POS, kitchen printing and purchasing displays.

In one embodiment, there is provided a booking system comprising a database arranged to provide seating availability in an entertainment venueand table availability in a restaurant, wherein a customer utilises aninterface to review the seating availability at the venue and theseating availability at a restaurant simultaneously, wherein allbookings and payments are undertaken via the interface.

In one embodiment, there is provided an interface that allows a customerto tailor a function space to a customer's requirements and providepayment autonomously, wherein all actions required to prepare thefunction space are created autonomously, including the creation of runsheets, table numbers, AV requirements, the placement of orders withsuppliers and the organisation of staffing requirements.

In one embodiment, the interface utilises feedback information from theuser, and optionally, historical data, to provide intuitive suggestionsto enhance a function experience and/or to offer an alternatives whenthe first preference is not available. This may include capturinginformation such as occasion type, experience sought, theme of event,group size, budget or other constraints.

In one embodiment table configuration options and alternatives areprovided for users via the user interface.

In one embodiment food menus, food menu packages and beverages andbeverage packages offered to booking requests are autonomously selectedin response to information received regarding the occasion, theme, styleof event and group size.

In one embodiment, the interface is arranged to provide a floor plan tothe user whereby the floor plan dynamically alters depending on thebooking information provided. This may include appropriate tableconfigurations, decorations, audio-visual equipment.

In one embodiment, the interface is arranged to provide a floor plan tothe user with drawing tools so that they can tailor the floor planspecifically to their personal requirements within the constraintsapplicable to and set by the venue.

In one embodiment, the function booking system recognises, evaluates andprices all items selected and placed on the floor plan together with anyother selection to provide the user an itemised quote and price for thefunction they have selected, designed and personalised, whereby the usercan make further changes, make a tentative booking, be provided areference number and be able to make further changes in the future upuntil which time a deposit would need to be paid to secure the functionroom or they would lose their tentative booking.

In one embodiment, should a subsequent user wish to book a space where aprevious user has a tentative booking on a space the user with thetentative booking receives an autonomous communication requesting thatthey confirm the tentative booking within a defined period of time.

Embodiments of the system, as described above, allows for the autonomousplacement of orders, invoicing, monitoring and management of the entiredelivery process for a confirmed function.

In one embodiment, position numbers are allocated to a table by thesystem and a user may utilise the interface to allocate guests againstthe defined position numbers. Once guests have been allocated toposition numbers, the system may autonomously contact the guests andinvite the guests to utilise the interface to pre-order and, ifappropriate, to pre-pay for the guest's share of the cost of a bookingor of the function. Name cards or place cards can also be selected as anoption to be printed and placed on the table(s) at a user's request.

In a fifth aspect, there is provided a computing system for optimisingthe use of space in a venue, comprising: a user interface providingmodule arranged to provide a user interface to at least one remote uservia a communications network, a user input receiving module arranged toreceive at least one request to reserve a space for a period of timewithin the venue from the at least one remote user via thecommunications network, a negotiation module in communication with aprocessor and arranged to receive the at least one request andcommunicate with a database to retrieve constraint information regardingthe venue and determine whether the at least one request can beaccepted, and if not, utilise the processor to retrieve informationregarding the other requests for spaces and propose at least onealternative request to the user via the user interface, wherein if theat least one alternative request is accepted by the user, the at leastone alternative request is saved in the database.

In one embodiment of the system an algorithm interrogates the databaseto determine what tables, booking times and booking durations have notbeen booked and make available for specific promotions. In a furtherembodiment the menus pricing and other terms and conditions for eachoffer can be determined by the system by matching the demand profile forthese available tables, times and durations with constraints anddifferent promotional packages set up by the venue.

In one embodiment of the system different promotional packages can beset up for which the algorithm can then select from to provide anincentive to accept alternate booking details. The promotional packagesthat can be set-up include: a percentage discount on the whole bill orpart of the bill, a percentage discount only on food or part of thefood, a percentage discount only on beverages or part of the beverages,the provision of various complementary items including a complimentaryglass of wine and a complimentary dessert. Further, the specificcircumstances to which these promotional packages can apply by service,by day, by date. For example, the maximum promotional benefit on aMonday may be greater than a Saturday, and the maximum potential benefitat a non-peak time may be greater than a peak time.

In one embodiment of the system the provision of an incentive orpromotional benefit for a customer to accept an alternate time offered,or alternate booking duration or more stringent terms and conditions.

In one embodiment of the system a person who has already made a bookingis able to log in and change the details of their booking.

In one embodiment of the system permit the booking requestor todetermine the seating position of their guests.

In one embodiment of the system permit the booking requestor to invitetheir guests to pre-order and part pay or pre-pay for their selections.

The negotiation module may propose at least one alternative requestusing past alternative request data retrieved by the processor from thedatabase.

The past alternative request data may include the frequency of theacceptance of the at least one alternative request by the user.

The negotiation module may be biased to propose at least one alternativerequest based on the relative frequency of the acceptance of the atleast one alternative request by the user when compared to otheralternative requests saved in the database.

The negotiation module may provide at least one alternative requestuntil such time as the request is abandoned by the user.

The at least one alternative request may include an autonomouslygenerated incentive to provide an incentive to the user to accept the atleast one alternative request.

The incentive may include at least one of a good and service related tothe at least one alternative request.

In a sixth aspect, there is provided a computer enabled method foroptimising the use of tables and table combinations in a venue,comprising the steps of: receiving at least one request to reserve atable or a table combination within the venue from at least one remoteuser from an application residing on a remote device via thecommunications network, as well as retrieving other information andconstraint information from the data base and using that information tocommunicate with a user prior to accepting a request for a booking andthen determining whether other requests for tables and tablecombinations have been made by other users, and if so, retrieveinformation regarding the other requests and information pertaining tothose requests for tables or table combinations and combine the at leastone request with other requests to form a pool of requests, and otherinformation pertaining to those requests retrieve constraint informationregarding the venue, and iteratively allocate all requests from the poolof requests utilising the restraint information to produce an optimisedtable and table combination allocation instruction set, wherein theoptimised prioritised and re-allocated, tables or table combinationsallocation instruction set is provided to one or more users associatedwith the venue.

In one embodiment of the system in a venue with one or more spaces analgorithm that can determine if the booking request can be categorisedinto one or more categories.

In one embodiment of the system the categories include a Super VIPcategory and a guaranteed table category where booking requests will beallocated to their selected table on a permanent basis if the specifictable requested is has not been previously allocated to a bookingrequest from the same category and by a higher requestor within thatcategory.

In one embodiment of the system where that booking request can becategorised in one or more spaces the optimisation algorithm toprioritise the allocation of the booking requests by the priority of thecategory.

In one embodiment of the system where more than one booking has beenreceived combine all the booking requests received with all priorbooking requests received to form a pool of booking requests andreallocate all the booking requests in accordance to the optimisationalgorithm and methodology to a pool of solutions comprising tables andtable combinations.

In one embodiment of the system the application of the followingmethodology:

-   -   a. allocating the received booking request to the requested        table or table combination;    -   b. allocating the received booking request to the requested        table or table combination by firstly identifying one or more        requestors associated with the booking request, and using the        identity of the one or more requestors to retrieve constraint        information including a requestor ranking relative to other        requestors, whereby the booking request is allocated based on        the requestor ranking;    -   c. where a requested table or table combination is already        allocated to a previous booking request, determining the        identity of the one or more requestors associated with the        booking request and using the identity of the one or more        requestors to retrieve constraint information including a        requestor ranking relative to the previous booking requestors,        and if the ranking of the requestor is higher than the ranking        of the previous booking requestor, reallocating the at least one        previously allocated booking request to a different table or        table combination to allow the received booking request to be        allocated to the requested booked table or table combination;    -   d. upon requiring a reallocation of at least one booking to        accommodate a received booking request, reallocating the at        least one previously allocated booking request by allocating the        booking request of the largest size first and reallocating all        other booking requests in descending order of size;    -   e. upon requiring a reallocation of at least one booking to        accommodate a received booking request, determining a booking        size metric of the received booking and each of the allocated        bookings by calculating a size metric which utilises the number        of persons that comprise the booking request and the service        time duration for the booking request as inputs, and utilising        the size metric to reallocate all bookings in order from the        largest size metric booking to the smallest size metric booking;    -   f. determining a difficulty metric utilising the size metric and        a peak period seating time value to determine a difficulty        measure, the difficulty measure representing a theoretical        measure of the relative difficulty in allocating the booking        request, whereby booking requests are ranked from most difficult        to least difficult and allocated in descending order from most        difficult to least difficult;    -   g. determining sub-service periods within a service period, and        for all booking requests that fall within the service period,        firstly allocating all booking requests that fall across one or        more sub-service periods in order of descending size, and        subsequently allocating all booking requests that do not fall        across the one or more sub-service periods in order of        descending size;    -   h. utilising constraint information to determine a difficulty        measure, the difficulty measure being representative of the        relative difficulty of allocating a booking request, whereby        bookings are allocated in descending order of difficulty;    -   i. reallocating at least one previously allocated booking        request to optimise the number of bookings within each of the        one or more spaces;    -   j. reallocating at least one previously allocated booking        whereby bookings of identical or similar size are clustered, in        both physical proximity and chronological proximity;    -   k. reallocating at least one previously allocated booking        whereby the total time that the each table or table combination        remains unused between bookings during a single service period        is minimised;    -   l. reallocating at least one previously allocated booking to        cluster bookings such that physically adjacent tables or table        combinations have similar start times;    -   m. reallocating at least one previously allocated booking such        that physically adjacent tables or table combinations have        similar finish times;    -   n. reallocating at least one previously allocated booking so        that smaller size bookings are physically clustered adjacent to        larger size bookings;    -   o. Reallocating at least one previously allocated booking such        that a previously joined table for an earlier booking in a        service period is reutilised for a later booking in the service        period;    -   p. reallocating at least one previously allocated booking such        that the at least one booking is allocated in a manner where a        minimal number of tables are joined or split to allocate the        booking;    -   q. reallocating at least one previously allocated booking such        that the total of bookings within a service period are arranged        in a manner that requires the least possible number of table        movements during the service period;    -   r. allocating at least one potentially conflicting booking to        the smallest fitting table or table combination irrespective of        availability, and where a conflicting booking is generated,        reallocating the previously allocated booking as a result of the        newly created conflicting allocation;    -   s. reallocating at least one previously allocated booking        whereby an empty table is retained between one or more booked        table or table combinations;    -   t. utilising constraint information to reallocate all bookings        from the highest ranked available table or table combination in        a descending order of rank,    -   u. reallocating at least one previously allocated booking        whereby the ranking of the booking requestor determines the        table or table combination allocated;    -   v. reallocating at least one previously allocated booking        utilising one or more qualitative constraints derived from        information associated with the booking requestor including but        not limited to a stated occasion associated with the booking, a        menu or courses selected by the requestor, the courses selected        by the requestor, ancillary products selected by the requestor        and the date of the booking; and    -   w. reallocating all bookings to one or more different table and        table combination solution sets to determine whether at least        one of the one or more different table and table combination        solution sets results in a more optimal outcome, and if so,        selecting the at least one of the one or more different table        and table combination solution sets that results in the more        optimal outcome.

In one embodiment of the system the ranking from best to worst of alltables and table combinations available for booking requests

In one embodiment of the system the relative location of each table andtable combination

In one embodiment of the system wherein the algorithm can determine ifadditional furniture can be brought in or removed from the availablelist of tables and table combinations if such action will result in amore optimised outcome.

In one embodiment of the system offering different menus and pricing fordifferent booking intervals, services, dates and dates.

In one embodiment the optimisation algorithm allows for the splitting ofa venue into spaces, subspaces, sections and or classes and for theallocation of tables and table combinations for each of the differentspaces, subspaces, sections and classes for the structured iterativeallocation process to be undertaken independently of each other.

In one embodiment, the data base includes menu information includingdifferent menus different numbers of courses per menu, different groupsizes, wherein the menu information is allocated different periods oftime, wherein, the menu information is utilised as part of theallocation of booking times accepted. The use of the menu informationprevents overlaps or conflicts.

In one embodiment, a pre-payment decision tree is provided whereby eachbooking request is reviewed to determine if pre-payment is required forthe booking to be secured. As an example, some form of pre-payment maybe required through the application of one or more constraints for aparticular booking request which could vary by day of week, a particularevent irrespective of the day, by peak and off-peak times on aparticular day, by menu selected, by courses selected, by group size, byoccasion using an algorithm to determine the best and most appropriaterequirement for the booking to a table or table combination.

In more detail, a seventh aspect of the embodiment provides a computingsystem for optimising the revenue and contribution of one or more spacesin a venue, which comprises a venue interface and input module to permitthe venue to enter information into the system utilised by the one ormore optimisation algorithms in the booking allocation process tooptimise the quantitative and qualitative outcomes of the space using atable and table combinations solution pool from which to find anoptimised outcome.

In one embodiment a computer system in a venue with one or more spacesfor optimising and allocating booking requests to tables and tablecombinations wherein the first allocation is not made until a specificpredetermined threshold has been reached or exceeded such as the numberof booking requests received or a specific time before the iterativeallocation or reallocation of all bookings to tables and tablecombinations

In one embodiment of the computer system wherein the tables and tablecombinations are arranged into subgroupings.

In one embodiment of the system where all the tables and tablecombinations are ranked utilising multiple criteria.

In one embodiment of the system where the constraint informationincludes customer information and third-party databases to rank the oneor more booking requests

In more detail an eighth aspect of the embodiment provides a computingsystem in accordance with the first aspect of the invention, whereinvenue constraints are varied utilising one of a forecasting modulearranged to use historical data to predict probable desired outcomes andan artificial intelligence engine arranged to review both historicaldata and external data to predict probable desired outcomes, wherein thepredicted outcomes are utilised to vary one of the venue constraintinformation and the strategy of the venue to in turn affect theoptimisation of quantitative and qualitative outcomes.

In one embodiment the matching of a booking requestors information withthe constraints of the venue to offer the booking requestor possibleoptions and plans based on their requirements as well as plans to add orremove objects to further personalise their needs and requirements.

In one embodiment of the system a pricing grid to provide pricinginformation for each plan and permitted personalisation variations.

In one embodiment the use of artificial intelligence to interact andbetter tailor and optimise the quantitative and qualitative constraintsto achieve the outcomes based on the strategy of the venue while bestmeeting the needs of the customer. The venues can include functionspaces, event spaces, workspaces hotel and accommodation

Broadly, a ninth aspect of the embodiment provides for a computingsystem for optimising the allocation of products and services providedby a venue. The services include booking times and durations, which arecontrolled such as by offering specific times and time durations,wherein associated products or services that offer the greatest revenueand/or other desired contribution are only made available during peaktimes and lower revenue products are made available during off-peakperiods to assist the optimisation of quantitative and qualitativeoutcomes based on the strategy of the venue. In other words, broadlyspeaking, embodiments of the system are arranged to vary offerings tobooking requestors based on the requirement and desirability ofproviding specific products during specific service periods or times. Inone embodiment, the invention is arranged to be optimised for the supplyof products to specific service industries which offer a combination ofthe rental (or occupation) of a physical space and the provision ofother products and services, such as hairdressers, car parks, massageservices, and other trade and professional services.

In one embodiment of the system in allocating online bookings usingcustomers information.

In one embodiment of the system filtering products so that availabilityis only shown to certain customers products, services, prices, times,durations and terms and conditions are only shown and made available tocertain customers and not to others. In one example, discriminating onthe availability and offers to customers based on a customer's ranking.

In a tenth aspect, there is provided a computing system for optimisingthe allocation of products and services for travel, aviation, cruising,rail, coach, holidays, car rental and other similar activities andbusinesses

In one embodiment where customers information can be used in thebookings and allocation process to offer a more personalised, morebespoke and more efficient service to customers while maximising theoptimisation of quantitative and qualitative outcomes based on thestrategy of the entity.

In one embodiment of the system filtering products so that availabilityis only shown to certain customer's products, services, prices and termsand conditions are only shown and made available to certain customers.In one example, discrimination the availability and offers based oncustomer's ranking.

In an eleventh aspect, there is provided a computer enabled method foroptimising the use of tables and table combinations in a venue,comprising the steps of: receiving at least one request to reserve atable or a table combination within the venue from at least one remoteuser from an application residing on a remote device via thecommunications network, as well as retrieving other information andconstraint information from the data base and using that information tocommunicate with a user prior to accepting a request for a booking andthen determining whether other requests for tables and tablecombinations have been made by other users, and if so, retrieveinformation regarding the other requests and information pertaining tothose requests for tables or table combinations and combine the at leastone request with other requests to form a pool of requests, and otherinformation pertaining to those requests retrieve constraint informationregarding the venue, and iteratively allocate all requests from the poolof requests utilising the restraint information to produce an optimisedtable and table combination allocation instruction set, wherein theoptimised prioritised and re-allocated, tables or table combinationsallocation instruction set is provided to one or more users associatedwith the venue.

In one embodiment the optimisation algorithm allows for the splitting ofa venue into spaces, subspaces, sections and or classes and for theallocation of tables and table combinations for each of the differentspaces, subspaces, sections and classes for the structured iterativeallocation process to be undertaken independently of each other.

In one embodiment, the data base includes menu information includingdifferent menus different numbers of courses per menu, different groupsizes, wherein the menu information is allocated different periods oftime, wherein, the menu information is utilised as part of theallocation of booking times accepted. The use of the menu informationprevents overlaps or conflicts.

In one embodiment, a pre-payment decision tree is provided whereby eachbooking request is reviewed to determine if pre-payment is required forthe booking to be secured. As an example, some form of pre-payment maybe required through the application of one or more constraints for aparticular booking request which could vary by day of week, a particularevent irrespective of the day, by peak and off-peak times on aparticular day, by menu selected, by courses selected, by group size, byoccasion using an algorithm to determine the best and most appropriaterequirement for the booking to a table or table combination.

In a twelfth aspect, there is provided a computing system for optimisingthe use of space in a venue, comprising: a user interface providingmodule arranged to provide a user interface to at least one remote uservia a communications network, a user input receiving module arranged toreceive at least one request to reserve a space for a period of timewithin the venue from the at least one remote user via thecommunications network, a negotiation module in communication with aprocessor and arranged to receive the at least one request andcommunicate with a database to retrieve constraint information regardingthe venue and determine whether the at least one request can beaccepted, and if not, utilise the processor to retrieve informationregarding the other requests for spaces and propose at least onealternative request to the user via the user interface, wherein if theat least one alternative request is accepted by the user, the at leastone alternative request is saved in the database.

The negotiation module may propose at least one alternative requestusing past alternative request data retrieved by the processor from thedatabase.

The past alternative request data may include the frequency of theacceptance of the at least one alternative request by the user.

The negotiation module may be biased to propose at least one alternativerequest based on the relative frequency of the acceptance of the atleast one alternative request by the user when compared to otheralternative requests saved in the database.

The negotiation module may provide at least one alternative requestuntil such time as the request is abandoned by the user.

The at least one alternative request may include an autonomouslygenerated incentive to provide an incentive to the user to accept the atleast one alternative request.

The incentive may include at least one of a good and service related tothe at least one alternative request.

In a thirteenth aspect, there is provided a computing system foroptimising the use of space in a venue, comprising a user interfaceproviding module arranged to provide a user interface to at least oneremote user via a communications network, a user input receiving modulearranged to receive at least one request to reserve a space within thevenue from the at least one remote user via the communications network,an optimisation module in communication with a processor and arranged toreceive the at least one request and communicate with a database todetermine whether other requests for spaces have been made by otherusers, and if so, utilise the processor to retrieve informationregarding the other requests for spaces and combine the at least onerequest with other requests to form a pool of requests, retrieveconstraint information regarding the venue, and iteratively allocate allrequests from the pool of requests utilising the restraint informationto produce an optimised space allocation instruction set, wherein theoptimised space allocation instruction set is saved in the database andprovided by a space allocation user interface to one or more usersassociated with the venue.

The restraint information may include the space available for allocationwithin the venue.

The database may include sub-space constraint information regardingsub-spaces with the space available within the venue, whereby theiterative allocation of requests includes utilising the sub-spaceconstraint information to optimise the allocation of space in the venue.

The database may include object constraint information regarding atleast one object arranged to be allocated to a space, whereby theiterative allocation of requests for spaces includes utilising theobject constraint information to optimise the allocation of space in thevenue.

The object constraint information may be information regarding thedimensions of one or more tables.

The sub-space constraint information may be information regarding asub-space within the venue.

The venue may be a restaurant.

In a fourteenth aspect, there is provided a computer enabled method foroptimising the use of space in a venue, comprising the steps ofreceiving at least one request to reserve a space within the venue fromthe at least one remote user via the communications network, determiningwhether other requests for spaces have been made by other users, and ifso, retrieve information regarding the other requests for spaces andcombine the at least one request with other requests to form a pool ofrequests, retrieve constraint information regarding the venue, anditeratively allocate all requests from the pool of requests utilisingthe restraint information to produce an optimised space allocationinstruction set, wherein the optimised space allocation instruction setis provided to one or more users associated with the venue.

In a fifteenth aspect, there is provided a computer system foroptimising the use of a restaurant, comprising: a database arranged toprovide historical and live data regarding the use of the resources of arestaurant, an input module arranged to receive information regardingthe actual usable resources at any given time, an optimisation module incommunication with a processor and arranged to receive the at least onerequest and communicate with the database to receive the historical andlive data and the actual usable resource data, wherein the data isanalysed utilising a yield determination algorithm to determine therelative optimal use of the usable restaurant resource. The optimisationmodule may provide information regarding one or more parameters that maybe optimised to increase the yield of the restaurant.

The historical data may be utilised by the algorithm to forecast futuredemand.

The database may include information from other restaurants, to providecomparison data.

The historical data may be utilised to calculate resource requirements.

In a sixteenth aspect, there is provided a computing system foroptimising the use of space in a venue across a defined period of time,comprising a user interface providing module arranged to provide a userinterface to at least one remote user via a communications network, auser input receiving module arranged to receive at least one request toreserve a space within the venue from the at least one remote user viathe communications network, the user further providing a period of timefor which the space in the venue is to be utilised, an optimisationmodule in communication with a processor and arranged to receive the atleast one request and communicate with a database to determine whetherother requests for spaces have been made by other users, and if so,utilise the processor to retrieve information regarding the otherrequests for spaces and combine the at least one request with otherrequests to form a pool of requests, retrieve constraint informationregarding the venue including the periods of time for which the requestsfor space are associated with, and iteratively allocate all requestsfrom the pool of requests utilising the time restraint information toproduce an optimised space allocation instruction set, wherein theoptimised space allocation instruction set is saved in the database andprovided by a space allocation user interface to one or more usersassociated with the venue.

The user interface may be arranged, in response to restraint informationprovided by the user, to provide additional restraint information to theuser, wherein the system provides an interface to allow the user toaccept the additional restraint information or alter their request.

The database may include menu constraint information regarding menusavailable, the menu constraint being dependent on the time periodconstraint information provided by the user, whereby the computingsystem provides a choice to the user to accept the additional restraintinformation or the user alters their request dependent on the menuconstraint information.

The database may include time and/or date constraint informationregarding at least the time and/or date that a space is available to beallocated wherein each block of time and/or date includes an indicatorarranged to allocate a relative rating to the time and/or date, whereinthe rating includes a constraint condition.

The computing system may further include a time and/or date optimisationalgorithm wherein the user is prompted to select a different time and/ordate depending on the output of the algorithm.

BRIEF DESCRIPTION OF THE DRAWINGS

Further features of the present invention are more fully described inthe following description of several non-limiting embodiments thereof.This description is included solely for the purposes of exemplifying thepresent invention. It should not be understood as a restriction on thebroad summary, disclosure or description of the invention as set outabove. The description will be made with reference to the accompanyingdrawings in which:

FIG. 1a is an extract from a manual reservations' diary;

FIGS. 1b-e are screenshots of the interface for various prior artbooking/table reservations systems;

FIG. 2a is an example computing system on which a method and/or acomputer program may be operated, in accordance with an embodiment ofthe invention;

FIG. 2b is an example of a flowchart illustrating a computer system uponwhich a computer enabled method may be operated, in accordance with anembodiment of the invention;

FIG. 2c , FIGS. 2d-i to 2d -iv, FIGS. 2e to 2f are flowchartsillustrating a computer enabled method in accordance with an embodimentof the invention;

FIG. 2g is a flowchart illustrating a diagrammatic representation of asystem in accordance with an embodiment of the invention as compared tothe prior art;

FIGS. 2h and 2i is a flowchart illustrating a diagrammaticrepresentation of a system in accordance with the prior art;

FIGS. 2j to 2m is a flowchart illustrating a diagrammatic representationof a system in accordance with an embodiment of the invention;

FIG. 3 is a flowchart illustrating a computer enabled method of thebooking process in accordance with an embodiment of the invention;

FIG. 4a is a flowchart illustrating a computer enabled methodoptimisation steps in accordance with an embodiment of the invention;

FIG. 4b is a diagram illustrating a volumetric and dynamicrepresentation of a floor plan in accordance with an embodiment of theinvention;

FIGS. 4c to 4e are floorplans illustrating the use of spaces, subspaces,sections, fixed and flexible seating area of a system in accordance withone embodiment of the invention;

FIGS. 5a to 5s are screenshots illustrating dynamic booking allocationsand a user interface screen in accordance with an embodiment of theinvention;

FIGS. 5t to 5u are diagrams illustrating table rankings within a classand customer rankings in accordance with an embodiment of the system;

FIGS. 6a to 6h are flow charts illustrating booking allocation rules anda user interface screen in accordance with an embodiment of theinvention;

FIGS. 7a to 7n is a screenshot illustrating a user interface screen inaccordance with an embodiment of the invention;

FIGS. 8a to 8g are screenshots illustrating a user interface screen inaccordance with an embodiment of the invention;

FIGS. 8h to 8j are constraints and flowcharts illustrating a computerenabled method for payment requirements and a pre-payment decision tree;

FIGS. 9a to 9i are screenshots illustrating constraint set-ups withinthe system including a menu decision tree, pre-order constraints, menuset-up, menu and course duration time set-ups, Super VIP and VIPoverrides, table reset times, alternate reporting calendar set-up anembodiment of the invention; and

FIGS. 10a to 10f are flowcharts illustrating a computer enabled processflow and interaction of the booking widget and/or app of the bookingprocess in accordance with an embodiment of the invention;

FIGS. 11a and 11b are flowcharts illustrating a computer enabled methodof the self-seating process in accordance with an embodiment of theinvention;

FIG. 12a is a flowchart illustrating a diagrammatic representation of asystem in accordance with an embodiment of the invention;

FIGS. 12b to 12d are screenshots illustrating the product tree andproduct set-ups in accordance with an embodiment of the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The present invention relates generally to a computing system, method,computer program and data signal for managing a venue with one or morespaces. In one embodiment which is described in more detail hereinbelow, the invention is directed to a computing system, computer enabledmethod, program and data signal which includes and one or more modules,the modules including algorithms arranged to receive venue constraintinformation regarding one or more aspects of the space and also receiverequestor constraint information regarding one or more aspects of thebooking request, and to use the received information to optimise bothquantitative and qualitative outcomes for both the booking requestor andthe venue.

The qualitative and quantitative outcomes may include improve theambiance of the venue in one or more spaces, optimising use of thespace, allowing booking requestors to request specific portions (e.g.tables or seating arrangements) or be allocated to a specific portion asa priority, offer and offering dynamic pricing and dynamicdifferentiated products and services. The algorithm provides true yieldmanagement, booking requestor self-management and an integrated andautonomous system. In one embodiment, the venue is a restaurant and theallocated portion may be a table, a seat at a bar, or any other seatingarrangement.

In more detail, one aspect of the embodiment described herein provides acomputing system for optimising the use of one or more spaces in avenue, which includes a user interface module arranged to provide a userinterface to at least one remote user via a communications network. Theembodiment further comprises a user input receiving module arranged toreceive at least one request to reserve a space within the venue fromthe at least one remote user via the communications network.

The embodiment also comprises an allocation module which is incommunication with a processor. The allocation module is arranged toreceive the at least one request and communicate with a database via aprocessor to determine whether other requests for spaces have been madeby other remote users.

If other requests for spaces have been made by other remote users, theallocation module either on receipt of a request or upon the activationof a trigger event utilises the processor to retrieve informationregarding the other requests for the one or more spaces and combines theat least one request with the other requests to form a pool of requests,retrieve constraint information regarding the venue, and iterativelyallocate all requests from the pool of requests utilising the constraintinformation to produce an optimised space allocation instruction set,wherein the optimised space allocation instruction set is saved in thedatabase and provided by a space allocation user interface to one ormore users associated with the venue.

Embodiments of the present invention use a knowledge of the dimensionsof the space and what the Applicant has dubbed a “volumetric” algorithmto optimise capacity and revenue within a single venue or a multi-venuerestaurant environment that can include diverse operations such as finedining, casual dining, cafes and cabaret shows. The system has anencoded algorithm which avoids the inherent constraints in prior artsolutions. All known prior art solutions are based on allocating bookingrequests to a set list of tables and table combinations using simplelook-up formulas. In a static allocation model, allocation consistssimply of finding the first available and suitable table in the setlist. In so called “dynamic” solutions, combinatorial constraintprogramming is used to allocate each booking request to a table or tablecombination. Combinatorial constraint programming, while theoreticallypossible, is not practical, as it is not computationally efficient andtherefore is not workable in the “real world”.

In broad terms, one primary difference between the embodiments describedherein and prior art is that the embodiment defines the problem to besolved as the “optimisation of the use of a space” using bothquantitative and qualitative constraints as compared to the prior art,that has defined the problem as the “management of tables” with priorart algorithms relying on the selection of the best fit table or tablecombinations from a predetermined list of tables and table combinationsto which a previous booking has not been allocated.

By defining the problem as the “optimisation of the use of a space” andusing volumetric algorithms with quantitative and qualitativeconstraints to solve the allocation problem of finding the optimal tableor seating location for each booking requestor, the embodiment providesan autonomous system which not only allocates booking requests in a muchmore optimal manner (since it can “weigh” and optimise for a series ofcomplex desired outcomes) but also operates across the entire experienceof the booking requestor, from the time a booking is requested, to thepersonalisation of the experience at the venue, until the service hasbeen completed and the bill paid. In the proceeding description of anembodiment, for the ease of reference, the complex set of desiredoutcomes that a venue wishes to deliver to a booking requestor(customer) will be referred to, in short form, as the “utility” derivedby the customer from the booking.

By defining the problem as the “optimisation of the use of a space”embodiments of the invention provide a fundamentally differentconceptualisation of the problem to be addressed, in that, in optimisinga restaurant, there are many more considerations than the randomallocation of booking requests to predefined tables and tablecombinations. To provide a specific example, a well-run restaurant, ifit is to maximise yield and grow customer loyalty, has to determine howto best use the space available, which includes the ability to allocatebooking requests to tables in a manner that takes into account otheraspects of the dining experience, such as the ambiance within therestaurant, the allocation of a person to their preferred location ortable, the distance between tables (which impacts on desirable qualitiesduring the dining experience such as privacy), the ability of therestaurant to offer different menus at different times and at differentprices to the same or different areas within a restaurant, allowingdiners to extend meal period times without causing strain on availableresources or conflicts with other bookings, offering different menus,offering personalisation to achieve the individual requirements andstrategies of different venues and restaurants in a way that also bettermeets customers' requirements and demands. As such, the “volumetric”algorithm described and defined hereinbelow is unique in that thealgorithm utilises quantitative and qualitative criteria to provide anintegrated and autonomous restaurant management system.

In the following description of an embodiment, specific terms will beused to broadly define particular features or aspects of the inventiveconcept or the information utilised to allocate a booking request,within the context of a specific example embodiment, namely theallocation of bookings in a restaurant.

Therefore, for the avoidance of doubt, in the embodiment described, theterm “booking requestor” is a broader term for a person or entityinteracting with the embodiment to make a booking request. Once abooking request is allocated, the booking requestor becomes a“customer”, “patron” or “diner” of the venue. In the example embodiment,the term “restaurant” is utilised as a proxy for the term “venue”,insofar as a restaurant is a practical example of a venue. The terms“space”, “sub-space” and “section” refer to specific delineated areas ofthe venue. The term “allocated portion” refers to the specific areawithin the venue that is allocated to the booking requestor. In the“real world” example embodiment described herein, the “allocatedportion” may be a table, a series of tables, a seat (such as a chair ora bar stool) or may simply be a physical space, devoid of specificfurniture. Therefore, where reference is made to customer beingallocated a table, table combination, a seat, etc., the reader is tointerpret this reference as a specific example of a booking requestorbeing allocated an “allocated portion”

The preferred embodiment detailed below has been described under variousheadings for ease of reference by the reader and to provide a logicaldeconstruction of the features and aspects that comprise the claimedinvention. However, it will be understood that the headings are providedmerely as a guide to the reader, and no gloss should be taken from theheadings to limit the embodiments or the broader inventive conceptdescribed herein.

In addition, while the description provided hereinbelow refers toaspects of the inventive concept that may be considered abstract innature, such aspects are described in the abstract for the purpose ofproviding context to the technical implementation and the technicalaspects of the claimed invention and no gloss is to be taken from theabstract description of underlying concepts to inherently limit thetechnical nature and scope of the invention. The Applicant makes noclaim over the abstract concepts described herein, only to theinherently technical implementation as claimed in the claims of thepresent specification.

Space Management and the Optimisation of Outcomes

Broadly, the embodiment described herein is directed to a system andmethod for optimising the use of a space by optimising the table layoutand seating capacity of a space in a venue (specifically a restaurant inthe embodiment described herein) without combinatorial constraintprogramming or the industry adopted, and practically applied approach ofstatic linear look-up formulas to allocate a booking a predefined set oftable or table combination to which a booking has not been previouslybeen allocated to.

The embodiment provides a software application embodied in a system anddeployed as a method that allows a user to create a plan of the venue toscale, as well as divide the venue into multiple spaces, multiple subspaces, multiple sections and multiple classes. Further, in the contextof the embodiment described herein, sections are designated as “flexiblespaces” where furniture is not fixed and can be moved and repositionedwhile spaces and subspaces, to the extent that they do not overlap witha section, are locations where furniture, once positioned, is fixed orsemi-fixed. That is, the furniture is either permanently fixed andtherefore cannot be repositioned, or the furniture can be replaced (i.e.swapped for another table or chair) but cannot be moved within thelocation.

In the context of the embodiments described herein, the terms “class”and “classes” are distinct to spaces, subspaces and sections, and areoverlayed as a layer “on-top” of spaces, subspaces and sections.

The term class refers to a number of qualitative characteristicsascribed to the area, which may include quantitative criteria andvariables that reflect qualitative aspects of the area. All spaces,subspaces and sections may be ascribed a class, as may an individualtable or seating arrangement. As an example, the qualitative andquantitative criteria and variables utilised to define a class mayinclude a relative ranking of a view, ambiance, privacy, required gapsbetween tables, menu available, number of courses, styles of service orother criteria utilised to differentiate between the relative“experience” or outcome afforded to the booking requestor.

In more detail, the embodiment allows for the encoding of the physicaldimensions and characteristics of all available furniture and otherrelevant objects, and the quantities of the furniture and objects,including their dimensions, such that a “to scale” plan or model can begenerated. Such a model also includes the dimensions and location ofother physical aspects of the venue, including doors, windows, kitchenand other preparation areas, toilets, etc., to enable the system tocalculate the relative spacing and relationship between each one of thefurniture and objects, to thereby determine the relative ability toplace furniture or objects within the space, and also to determine therelative utility of placing the furniture and objects within the space,including the utility for specific booking requests, where a bookingrequestor has provided specific constraint information that therequestor wishes to satisfy in order to proceed with the booking.

This feature allows additional furniture to be brought into the space tocater for unusual booking requests. Moreover, yield and utility areoptimised as the ability to position or reposition furniture or objectsallows, for example, additional tables to be brought into the spaceunder certain circumstances, such as where additional space is createdas a result of joining tables together.

Correspondingly, the embodiment is capable of removing tables, incircumstances where a more optimised allocation may be achieved byremoving tables from the space.

Such a feature is particularly useful for restaurants that have theability to maintain a store of additional furniture in varyingquantities and sizes. For example, it may be possible within a fixed orflexible space to interchange two round tables seating 6 people eachwith a number of rectangular tables that can seat 12 people when joined,thereby allowing a booking of 12 people to be taken on a single table byinterchanging the round tables with smaller but joined rectangulartables.

Different spaces, subspaces and sections within the restaurant aredefined with a table location index from which the system can then addtable numbers to tables in sequential order when they are placed withina floor plan. Further, the table numbers dynamically vary in accordancewith changes to the booking allocations, table layouts and number oftables used.

In one embodiment of the system a user can set up a reference floor planlayout as a reference point for the venue operator from which bookingscan be allocated to. However, the system is not limited to using thetables and layout shown on the reference floor plan and can rearrangethe tables by joining them, replacing them and/or removing them if amore optimised outcome is achieved by such variation. To assist thevenue operator in their understanding of the changes made by the system,the system display changes and additional tables introduced by thesystem in a different colour.

The embodiment also includes further information which can be utilisedto determine the “best” table to use within the allocated portion. Thebest table, being determined by the requestor constraint information andthe venue constraint information for each booking request. For example,the best table for which to place a booking request may be a windowtable for a special occasion or for a booking willing to pay a premium,or the best table may be a quiet table for a business meeting or thebest table may be one with no view for a booking request on a limitedbudget. Alternatively, the best table may be defined by the venue as thetable that provides the highest revenue or permits the greatest numberof bookings or the table that maximises the utilisation of the floorspace. The embodiment also allows the venue to vary the parameters as towhat it defines as the best table by service and by day to give thevenue greater flexibility in meeting customer demand within its ownstrategy as well as allowing greater differentiation from competitors.

To achieve the varied desired outcomes, which may also vary at differentpoints in time as well as vary depending on the demand profile for aparticular service period, several individual algorithms can beselectively used in isolation or in combination to create a system andmethod for optimising the required outcomes. In one embodiment, thesystem is capable of eliminating unused space within a venue orrestaurant when tables are required to be joined to form a larger tableto cater for a larger booking size.

Advantageously, the system dispenses with the requirement for the inputof a list of specific tables and table combinations as the system usesthe physical characteristics of the furniture and objects, and the spaceto place all furniture and objects within the venue to generate a floorplan.

Customer Relationship Management

Broadly, the embodiment also provides a system and method for optimisingthe quantitative and qualitative outcomes of use of a space byoptimising booking allocations to a table or a space while meetingqualitative outcomes and taking into account constraints such as therequirements of regular customers.

In one embodiment the system is linked to a venue's customer databaseand/or other third-party databases to determine the identity of thebooking requestor. More particularly, where available, historical orpreferential data relevant to the booking requestor can be accessed.Such data may include a ranking ascribed to the requestor, a preferredtable or seating location within the restaurant, the number of previousvisits, a spend amount per visit, a spend per person per visit, or anyother information that may have an impact on the table allocated to therequestor. Such information is combined to determine a rank or similarmetric, which is then utilised in the booking allocation process.

In one embodiment of the system, customers can be placed into variouscategories including the categories of Super VIP, VIP and a category forall other customers. The venue may select, in the embodiment, whetherthe categories are utilised in the booking allocation process. Forexample, the embodiment provides a feature whereby seating for selectedcustomers such as Super VIP's is automatically allocated, guaranteed andfixed to their preferred table or location irrespective of otherconstraints, while maintaining the ability to optimise the use of aspace around customers allocated to their preferred location. Similarly,VIP's can be allocated to their preferred location, but only if such anallocation does not adversely affect the optimisation of other requiredoutcomes within the venue. Lastly, the allocation of all other bookingscan be optimised to ensure that individual the customer experience isstill maximised to the extent possible, by allocating tables in order ofa ranking system.

As a corollary, the algorithm allows for the reallocation of bookingswithin a space so that regular requestors are provided with relatively“better” locations within the venue as compared to non-regularrequestors.

It will be understood that in the context of the embodiment describedherein, the terms “better” and “best” (and similar terms) are used todescribe a location and/or table that may be qualitatively orquantitatively determined to be more desirable to either the bookingrequestor or to the venue, relative to other locations and/or tableswithin the venue.

The determination of which table is “better” or “best” is determined bycalculating a metric value utilising a number of input values, as shownin FIG. 5t . The metric value takes into consideration intrinsiccharacteristics of the location in the venue of the table (e.g. is thetable near a window or near the kitchen door? is the table in a quietlocation or a noisy location? is the distance between the table and thenext table large or small? Etc.) as shown generally at table 581. Itwill be understood that the metric may take into account any number ofqualitative or quantitative variables that are relevant to describingthe location of the table in the venue. Each variable, in turn, may beweighted accordingly. For example, in a restaurant with water views, theview from the table may be a variable that is more heavily weighted thanwhether the location is a quiet location. Therefore, tables with a waterview may be ranked relatively higher than tables which are in a quietarea of the restaurant. The system allows the venue to set suchvariables in a manner that is consistent with the strategy and image ofthe restaurant.

It will be understood that the metric may be fixed, or may vary overtime, depending on the relative importance of each input value due toother extrinsic factors. For example, a higher weighting may be ascribedto quiet tables during a lunch service, when privacy is more desirablefor business customers, whereas a higher weighting may be ascribed totables in a more central area of the venue during dinner service, wherecustomers prefer a more lively atmosphere. Examples of the relativevalues ascribed to each characteristic is shown at table 583 of FIG. 5t.

Following on from the previous points, the algorithm can optimiseambiance and customer satisfaction by allocating the “best” tables tobooking requests when the restaurant is not full. This is important whena space or a restaurant is not full as optimisation of the floor spacemay not achieve the best outcome for the restaurant as the provision ofthe best space for a booking may result in a customer being happier andpossibly spending more than if they were seated in a worse space or ifthe bookings are concentrated in one area of the restaurant.

Correspondingly, as shown in FIG. 5u , customers may also be providedwith a “ranking”. At 587, there is shown a deliberately simplifiedexample (for the purposes of the present specification) of the manner inwhich customers may be ranked. Depending on the ranking as determined attable 587, customers may be allocated a numerical ranking valueaccording to table 589, which may then be used to match a customerranking to a table ranking, or for any other suitable purpose.

Dynamic Floor Plans

Broadly, the embodiment described herein includes an interface arrangedto communicate the determined allocation of booking requests (and theresultant table and seating arrangement) to a user (typically restaurantstaff) through a dynamic “real time” floor plan displayed on the userinterface. In this manner, staff are able to arrange the restaurantahead of a service time. Moreover, the floor plan, in one embodiment, isutilisable as part of a self-seating process.

In one embodiment the “real time” dynamic floor plans depict the floorplan and table layout within the venue at any future point in time, suchthat, the floor plans and table layouts can be communicated to andprovided to any user including a booking requestor.

In one embodiment of the system there is provided a widget, app, orother form of software application which may be utilised on a mobilecomputing device or incorporated into a kiosk located at the venue. Thesoftware or device permits a walk-in customer to a venue to make abooking request (as described above) and also to be given directions viathe real time dynamic floor plan as to the location of the allocatedportion, so that the booking requestor can undertake a self-seatingprocess.

Where an allocated portion is not immediately available, the bookingrequestor is advised as to the future availability of an allocatedportion and the requestor can select whether to be placed on the waitlist or to cancel the request. In some instances, a booking requestormay be provided with an incentive to accept a different booking time.The incentive may take any known form, such as a free drink at the bar,or a discount or a complimentary product such as a glass of wine whenthey return and are seated. The system monitors the use of the table andsends the waitlisted booking requestor an email and/or text message whenthe table is ready.

Menus, Courses, Duration Times and Group Sizes (Variable Products)

In the context of the specification and the embodiment described herein,the services generally offered by a restaurant are commonly referred toin the industry as “products” but may include a mixture of products andservices. That is, a product can be a number of courses associated witha menu, a menu item, a beverage, or a combination thereof.

A product has specific attributes and those attributes can include anassociation with a specific service period, booking time, bookingduration time, day of the week, date, group size and/or occasion.

The product may include or be associated with one or more services,including extended duration time, location within a venue, class oftables within a venue specific type of table, specific table within avenue, specific level of service.

The product can include third party items such as flowers,entertainment, etc.

A cost associated with the product may be set dynamically by time, groupsize, occasion, table location, specific table, payment of booking fees,additional services, discounts or promotional pricing.

In one embodiment the system a plurality of different menus are providedand each menu is associated with one or more service periods or specifictimes within a service period. Similarly, particular menus may beassociated with specific group sizes (i.e. booking sizes), with bookingrequests for specific occasions (e.g. a birthday, an anniversary,Valentine's day, etc.) and with any other variable that may have animpact on the constraints under which a booking is to be allocated. Themenus are utilised by one or more optimisation algorithms within theallocation module to either provide various constraints (which aredisplayed as options to a booking requestor) at the time that therequestor makes the initial booking request, or alternatively to offeran alternative option (set of constraints) to the booking requestor,should the booking requestors primary request not be allocable by thealgorithm. For example, booking requestors, in one embodiment, can viewavailable capacity by menu and by courses.

It will be understood that menu constraints may also be associated witha space, subspace section or class for use by the one or moreoptimisation algorithms as a constraint when undertaking the bookingallocation process.

It will be understood that the system also allows for a “table reset”time to be associated with each booking request, such that an amount oftime is allowed between consecutive bookings to ensure that eachallocated booking can be adequately serviced by the venue. Moreover, thetable reset time may be varied depending on any other relevantconstraint. For example, the table reset time may be different dependingon class, the service period, the space, sub-space or section, or anyother constraint that has an impact on the amount of time required toreset a table and receive a new booking.

It will be understood that different menus, courses and durations mayalso be provided to a booking requestor dependent on the identity of therequestor. For example, VIP customers and regular customers can beoffered different menus, courses and durations.

The algorithm also allows for multiple seating periods during a serviceperiod with the allocation algorithm allocating booking requests foreach seating period while taking into account the previous seatingperiod and the next seating period. The algorithm can also optimise forbookings that cross over one or more seating periods.

Variable Pricing

As described above, a product has specific attributes and thoseattributes can include an association with a specific service period,booking time, booking duration time, day of the week, date, group sizeand/or occasion.

The product may include or be associated with one or more services,including extended duration time, location within a venue, class oftables within a venue specific type of table, specific table within avenue, specific level of service.

The product can include third party items such as flowers,entertainment, etc.

As such, it follows that a cost associated with the product may be setdynamically by time, group size, occasion, table location, payment ofbooking fees, additional services, discounts or promotional pricing.

In more detail, as the system is capable of providing different seatingperiods, different menus, different classes, different seatingarrangements and can optimise according to requestor constraintinformation (i.e. can personalise the experience and service deliveredto each individual requestor), it follows that differential pricing maybe associated with one or more of the options (constraints) associatedwith the allocated booking.

For example, differential pricing may be associated with differentservice periods, different booking times, extended booking times,specific tables, sections, sub-spaces and spaces, different classes, andany other venue constraint relevant to the cost of delivering therequested booking and service.

As a corollary, it will be understood that the system is capable offurther optimising by calculating the cost, revenue and gross/net profitassociated with each possible permutation of a booking request, as wellas whether other permutations exist which may increase the utility ofthe booking requestor, and may utilise the calculated cost andhypothetical increased utility to the requestor to determine the mannerin which yield may be increased, and correspondingly provide inducementsto booking requestors to select options (i.e. “upgrades”) which providea more optimal experience for the booking requestor, provide a moreoptimal yield to the venue, or a combination of both. In the embodiment,this may take the form, for example, of the system offering to upgrade abooking, for an incremental increase in cost to the requestor, to atable with higher utility (in accordance with the constraint informationprovided by the requestor).

The further optimisation may also be provided to group booking requestsand to booking requests where the identity of the requestor places themin a particular grouping. For example, VIP customers and regularcustomers can be offered different menus at different pricing which inturn determines aspects of the booking allocation process.

Booking Request Personalisation

The requestor constraint information may include a request for aspecific table. In turn, the allocation algorithm may allocate thespecific allocation portion dependent on a number of other constraints,including the identity of the booking requestor, the status of thebooking requestor, the availability of the table, the payment of anadditional amount, or any other constraint relevant to the allocation ofa specific allocation portion.

In one embodiment of the system a venue is able to offer a bookingrequestor the ability to order ancillary or third party items relevantto the booking. For example, the booking requester may request aspecific staff member to attend, a bucket of champagne next to theirtable upon arrival, flowers on the table upon their arrival and otherpersonalised items including entertainment to permit a booking requestorto personalise their dining experience.

Yield Management

In more detail, a third aspect of the embodiment described hereinprovides a computing system for optimising the revenue and contributionof one or more spaces in a venue, which comprises a venue interface andinput module to permit the venue to enter information into the systemwhich permits the strategic control of inventory by space, subspace,section and class with information regarding the menus, courses andservices being offered to the booking requestor at “the right time andfor the right price”. The information is utilised by the one or moreoptimisation algorithms in the booking allocation process to optimisethe quantitative and qualitative outcomes of the space in accordancewith the yield requirements of the venue. Moreover, the yieldrequirements may vary over time in a manner that allows yield to beimproved over successive service periods.

In one embodiment of the system the constraints concerning the utilityof different tables, spaces, subspaces, sections and classes and thepeak demand times are combined with constraints that provide the abilityto differentiate between different menus, courses, different servicestandards, different products and services, different duration times,different pricing policies within a venue and combine the sets ofconstraints to permit the strategic determination and control ofcapacity by offering dynamic product changes and dynamic pricing changessuch that revenue and yield can be monitored and used as inputs by theone or more optimisation algorithms as part of the booking allocationprocess.

For example, the system may offer a booking requestor an alternatebooking time or menu or duration period at an alternate price if therequested time and menu are not available as part of the bookingallocation process. As a corollary, the system can charge a higher orlower price depending of the demand for a particular service or menu ortime or table or area or class as part of the booking allocationprocess.

In one embodiment the system can increase or decrease the amount oftables offered within a class if demand varies markedly within thatclass.

In one embodiment the system can search and locate tables with unbookedtime periods and offer special and promotions in an effort to fill thosetables and times.

In one embodiment the system can use the information provided by thebooking requestor to make suggestions and recommendations of items andselections to enhance the experience of the booking requestor.

In one embodiment the system can calculate metrics related to theperformance of the revenue generating processes and the efficiency ofthose processes so that these metrics can be used in future yieldmanagement decisions as well as forecasting and as decision variablesfor a completely autonomous process.

In one embodiment, the invention is directed to controlling, allocating,forecasting and optimising capacity to improve revenue efficiencies byusing yield management algorithms to optimise restaurant-relatedoutcomes and efficiencies.

In a fourth aspect, there is provided an autonomous, integrated bookingand management system.

Self-Seating, Pre-orders, Venue Orders and Point of Sales Systems

In one embodiment, the system provides a self-seating facility forwalk-in customers and a facility for pre-booked customers to check theirtable allocation together with the provision of a dynamic real-timefloor plan with directions on the location of the requestor's allocatedtable. There is also provided a wait list facility with automaticcommunication so that a customer who is placed on a waitlist can beadvised of when a requested table is available.

In one embodiment the system provides dynamic real-time plans topre-booked customers arranged to show the forecasted floor plan upontheir arrival with directions as to locate their table for self-seatingpurposes.

In one embodiment, the dynamic real time floor plan is provided as anintegrated component of a point of sale system so that a venue userusing the point of sale system can refer to a correct floor plan thatdepicts dynamically updating table numbers and layout.

In one embodiment there is provided, via the user interface, electronicmenus from which booking requestors can pre-order a meal as part of thebooking allocation process. The electronic menus are integrated with aproduct tree and classification system such that the resources requiredto prepare a meal can be tracked for cost, resource and revenuepurposes.

As a corollary, the payment required for a booking and a meal aredetermined by a payment decision tree which also utilises requestorconstraint information and venue constraint information to determinewhether the venue requires a deposit or a pre-payment to be made inorder to confirm the booking.

In one embodiment the system includes an integrated gift certificateacceptance module or is capable of interfacing with a third party giftcertificate module.

In a further embodiment, the invention is capable of integrating withother systems and/or may incorporate other systems within the embodiment(such as by accessing an API) to create an integrated autonomousrestaurant system that operates to control the restaurant managementprocess, beginning at a booking, through to when the booking requestorleaves the restaurant after the booking.

Function Diary Integrated with the Restaurant Diary

In one embodiment there is provided a restaurant booking diary with anassociated optimisation algorithm arranged to optimise restaurantbookings, and a corresponding function booking diary wherein anoptimisation algorithm is provided for function bookings, due to therequirement for greater personalisation and changes to restaurantsstandard operations, floor plans, pricing menus and order of service.

The optimisation algorithm for function bookings is arranged to changethe recommended floor plan offered to a function booking requestor inresponse to the information provided by a booking requestor. Forexample, the floor plan suggested for a wedding with 60 people would bedifferent to a floor plan for 100 people, which would be different againfor a floor plan for a 60 person business event or a 60 person hen'sparty. Moreover, the recommended menus, pricing, availabilities,restrictions and terms and conditions are also varied depending on theinformation provided by the booking requestor.

In one embodiment, the system provides a function planning module,arranged such that a booking requestor can allocate guests to tablesincluding positions at those tables as well as sending invitations toguests with confirmation information, directions, transportation and carpark details so as to provide a full service arrangement including thirdparty services such as flowers, audio visual equipment andentertainment.

Dashboard for the Reservations System and Diary

In one embodiment there is provided an integrated interface such thatthe user can view all information required to manage a service periodwithin a restaurant on a single screen, which functions as a controldashboard. Where additional information is required pop-up windows areprovided so that the user is never more than “one click” away from anyinformation required to manage the restaurant in real time.

In one embodiment of the system the dashboard includes at least one of afloor plan and a Gantt chart, a booking list displaying booking detailsand a communications panel. In a further embodiment the communicationspanel displays emails, text messages, bookings taken during service,wait lists, standby lists, home delivery orders and takeaway orders toensure that all information is within a single interface without therequirement to utilise other systems.

In other words, the visual interface affords complete integration withall restaurant systems, widgets and apps including self-seating, homedelivery and takeaway orders, point of sale systems, staff attendanceand rostering and purchasing.

Rostering and Scheduling System

In one embodiment, historical booking information and future bookinginformation is utilised with forecasted information and staffavailability information for the generation of staff rosters.

In one embodiment, the user can enter staff to customer ratios and otherstaff performance standards for the system to use together with expectedbookings for the creation of staff rosters. In a further embodiment themonitoring and measurement of staff performance against the performancestandards and the provision of recommendations for changes andimprovements.

Purchasing System

In one embodiment, all pre-orders, confirmed and booked functions, homedelivery orders, take away orders taken through the reservations systemand dashboard and the point of sales system are visible via the singleinterface.

In one embodiment, the venue is capable of ordering food, beverages andservices from third parties directly through the system.

Booking two Venues at the Same Time

In one embodiment, the booking requestor can book two or more venuessimultaneously as part of the same booking request. For example, thebooking requestor may book theatre tickets and make a restaurantbooking.

Restaurant Table simulator and Table Configurator

In one embodiment the user is capable of manually defining multipledifferent spaces within a venue. That is, multiple spaces, subspaces andsections of different sizes and different orientations can be defined,with a corresponding mix of fixed and flexible table areas and differenttable sizes and quantities.

Correspondingly, the allocation algorithm allows restaurants and venuesto run booking simulations to determine the best orientation, spacingand layout of tables and furniture within a restaurant or a venue todetermine the best solution based on the restaurants requirements so toassist in the restaurant planning process such as determining what sizetables to buy, how many tables to buy, how many chairs to buy and otherphysical decisions within the restaurant.

Home Delivery, Take-Away Order and Pick-up

In one embodiment of the system all online orders are co-ordinated andcontrolled by the system to ensure that orders are controlled in aco-ordinated way, wherein the kitchen and other resources within therestaurant are properly managed and not overburdened. Moreover, suchcontrol allows for detailed communication with the customer.

Gift Certificates

In one embodiment, the system is capable of accepting gift certificatesas a form of pre-payment.

In more detail, a fifth aspect of the embodiment described herein whichprovides a computing system for optimising the revenue and contributionof one or more spaces in a venue, which comprises a venue interface andinput module to permit the venue to enter information into the systemutilised by the one or more optimisation algorithms in the bookingallocation process to optimise the quantitative and qualitative outcomesof the space in a way that offers alternate options, customerinteraction, marketing and promotion.

Alternate Options

In one embodiment, there is provided a promotions module arranged tointerrogate the database to determine what tables, booking times andbooking durations have not been booked for a specific service period,and correspondingly automatically generate and publish/communicatespecific promotions, using yield information to ensure that thepromotions maintain a desired outcome/yield.

In a further embodiment, the pricing for items on the menu and the termsand conditions associated with each promotional offer is determined bythe system by utilising the demand profile for the available tables,times and durations and constraint information to optimise a desiredoutcome.

Marketing and Promotion

In one embodiment, the constraints utilised by the promotional moduleinclude providing a percentage discount on the whole bill or part of thebill, a percentage discount only on food or part of the food, apercentage discount only on beverages or part of the beverages, theprovision of various complementary items including a complimentary glassof wine and a complimentary dessert. Further, the constraints caninclude specific circumstances to which promotional packages can apply,limited by service period, by time, by day of the week and/or by date.For example, the maximum promotional benefit on a Monday may be greaterthan a Saturday, and the maximum potential benefit at a non-peak timemay be greater than a peak time.

Customer Interaction

In one embodiment, the interface allows a booking requestor to alter thedetails of their booking.

In one embodiment, the interface permits the booking requestor todetermine the seating position of all persons that form part of thebooking request.

In one embodiment, the system permits the booking requestor to send amessage to all persons associated with the booking request, wherein eachperson associated with the booking request can interact with theinterface to pre-order and part pay or pre-pay for their selections.

In more detail, a sixth aspect of the embodiment described herein whichprovides a computing system for optimising the revenue and contributionof one or more spaces in a venue, which comprises a venue interface andinput module to permit the venue to enter information into the systemutilised by the one or more optimisation algorithms in the bookingallocation process to optimise the quantitative and qualitative outcomesof the space using a table and table combination solution pool fromwhich to find an optimised outcome.

Table and Table Combination Categories

In one embodiment of the system in a venue with one or more spaces analgorithm that can determine if the booking request can be categorisedinto one or more categories.

In one embodiment of the system the categories include a Super VIPcategory and a guaranteed table category where booking requests areallocated to their selected table on a permanent basis if the specifictable requested is has not been previously allocated to a bookingrequest from the same category and by a higher requestor within thatcategory.

In one embodiment of the system where that booking request can becategorised in one or more spaces the optimisation algorithm toprioritise the allocation of the booking requests by the priority of thecategory.

In one embodiment of the system where more than one booking has beenreceived combine all the booking requests received with all priorbooking requests received to form a pool of booking requests andreallocate all the booking requests in accordance to the optimisationalgorithm and methodology to a pool of solutions comprising tables andtable combinations.

In one embodiment of the system the allocation algorithm utilises atleast one or more of the following steps to allocate booking requests:

a. allocating the received booking request to the requested table ortable combination;

b. allocating the received booking request to the requested table ortable combination by firstly identifying one or more requestorsassociated with the booking request, and using the identity of the oneor more requestors to retrieve constraint information including arequestor ranking relative to other requestors, whereby the bookingrequest is allocated based on the requestor ranking;

c. where a requested table or table combination is already allocated toa previous booking request, determining the identity of the one or morerequestors associated with the booking request and using the identity ofthe one or more requestors to retrieve constraint information includinga requestor ranking relative to the previous booking requestors, and ifthe ranking of the requestor is higher than the ranking of the previousbooking requestor, reallocating the at least one previously allocatedbooking request to a different table or table combination to allow thereceived booking request to be allocated to the requested booked tableor table combination;

d. upon requiring a reallocation of at least one booking to accommodatea received booking request, reallocating the at least one previouslyallocated booking request by allocating the booking request of thelargest size first and reallocating all other booking requests indescending order of size;

e. upon requiring a reallocation of at least one booking to accommodatea received booking request, determining a booking size metric of thereceived booking and each of the allocated bookings by calculating asize metric which utilises the number of persons that comprise thebooking request and the service time duration for the booking request asinputs, and utilising the size metric to reallocate all bookings inorder from the largest size metric booking to the smallest size metricbooking;

f. determining a difficulty metric utilising the size metric and a peakperiod seating time value to determine a difficulty measure, thedifficulty measure representing a theoretical measure of the relativedifficulty in allocating the booking request, whereby booking requestsare ranked from most difficult to least difficult and allocated indescending order from most difficult to least difficult;

g. determining sub-service periods within a service period, and for allbooking requests that fall within the service period, firstly allocatingall booking requests that fall across one or more sub-service periods inorder of descending size, and subsequently allocating all bookingrequests that do not fall across the one or more sub-service periods inorder of descending size;

h. utilising constraint information to determine a difficulty measure,the difficulty measure being representative of the relative difficultyof allocating a booking request, whereby bookings are allocated indescending order of difficulty;

i. reallocating at least one previously allocated booking request tooptimise the number of bookings within each of the one or more spaces;

j. reallocating at least one previously allocated booking wherebybookings of identical or similar size are clustered, in both physicalproximity and chronological proximity;

k. reallocating at least one previously allocated booking whereby thetotal time that the each table or table combination remains unusedbetween bookings during a single service period is minimised;

l. reallocating at least one previously allocated booking to clusterbookings such that physically adjacent tables or table combinations havesimilar start times;

m. reallocating at least one previously allocated booking such thatphysically adjacent tables or table combinations have similar finishtimes;

n. reallocating at least one previously allocated booking so thatsmaller size bookings are physically clustered adjacent to larger sizebookings;

o. Reallocating at least one previously allocated booking such that apreviously joined table for an earlier booking in a service period isreutilised for a later booking in the service period;

p. reallocating at least one previously allocated booking such that theat least one booking is allocated in a manner where a minimal number oftables are joined or split to allocate the booking;

q. reallocating at least one previously allocated booking such that thetotal of bookings within a service period are arranged in a manner thatrequires the least possible number of table movements during the serviceperiod;

r. allocating at least one potentially conflicting booking to thesmallest fitting table or table combination irrespective ofavailability, and where a conflicting booking is generated, reallocatingthe previously allocated booking as a result of the newly createdconflicting allocation;

s. reallocating at least one previously allocated booking whereby anempty table is retained between one or more booked table or tablecombinations;

t. utilising constraint information to reallocate all bookings from thehighest ranked available table or table combination in a descendingorder of rank;

u. reallocating at least one previously allocated booking whereby theranking of the booking requestor determines the table or tablecombination allocated;

v. reallocating at least one previously allocated booking utilising oneor more qualitative constraints derived from information associated withthe booking requestor including but not limited to a stated occasionassociated with the booking, a menu or courses selected by therequestor, the courses selected by the requestor, ancillary productsselected by the requestor and the date of the booking; and

w. reallocating all bookings to one or more different table and tablecombination solution sets to determine whether at least one of the oneor more different table and table combination solution sets results in amore optimal outcome, and if so, selecting the at least one of the oneor more different table and table combination solution sets that resultsin the more optimal outcome.

In one embodiment the ranking of all tables and table combinationsavailable for booking requests.

In one embodiment the relative location of each table and tablecombination.

In one embodiment the algorithm can determine if additional furniturecan be brought in or removed from the available list of tables and tablecombinations if such action will result in a more optimised outcome.

In one embodiment, the system offering different menus and pricing fordifferent booking intervals, services, dates and dates.

In more detail, a seventh aspect of the embodiment described hereinwhich provides a computing system for optimising the revenue andcontribution of one or more spaces in a venue, which comprises a venueinterface and input module to permit the venue to enter information intothe system utilised by the one or more optimisation algorithms in thebooking allocation process to optimise the quantitative and qualitativeoutcomes of the space using a table and table combinations solution poolfrom which to find an optimised outcome.

Table and Table Combination Threshold

In one embodiment a computer system in a venue with one or more spacesfor optimising and allocating booking requests to tables and tablecombinations wherein the first allocation is not made until a specificpredetermined threshold has been reached or exceeded such as the numberof booking requests received or a specific time before the iterativeallocation or reallocation of all bookings to tables and tablecombinations.

In one embodiment of the computer system wherein the tables and tablecombinations are arranged into subgroupings.

In one embodiment of the system where all the tables and tablecombinations are ranked.

In one embodiment of the system where the constraint informationincludes customer information and third party databases to rank the oneor more booking requests.

In more detail, an eighth aspect of the embodiment described hereinwhich provides a computing system for optimising the revenue andcontribution of one or more spaces in a venue, which comprises a venueinterface and input module to permit the venue to enter information intothe system utilised by the one or more optimisation algorithms in thebooking allocation process to optimise the quantitative and qualitativeoutcomes of the space for functions, events, workspaces hotels andaccommodation.

In one embodiment of the system in a venue with one or more spaces anonline booking system and one or more algorithms that can optimise andallocate furniture within a space such that it is tailored to therequirements of the requestor

In one embodiment of the system in venue a function space venue, anevent space venue or a hotel or other accommodation venue.

In other words, in one embodiment the system seeks to manage the entireguest experience from time of booking with the ability to handlepre-orders, pre-payments, part-payments, invitations to booking gueststo pre-order and prepay, amendments to bookings, personalisation andtailoring of booking requests, automatic seating allocations andself-seating directions, automatic ordering at a table, pre-order,automatic printing of orders in the kitchen, taking of home deliveryorders and automatic printing of home delivery orders into the kitchen,the management of a la carte and home delivery orders in the kitchen andestimation of cooking times and when the food will be ready, the issuingof gift certificates and the redemption of the gift certificates aspayment or part-payment for an order, the simplification and processingof final payments through a point of sale system and integrated CustomerRelationship Management (CRM), accounting, reporting, budgeting andforecasting.

In a ninth aspect one of an embodiment of the system the allocation ofonline bookings for a services where the availability of those servicesare controlled, limited and offered for specific times and timedurations such that the products or services offered are arranged suchthat products and services with the greatest revenue and contributionare only made available during peak times and lower revenue products andservices are made available or offered during off-peak periods to permitthe optimisation of quantitative and qualitative outcomes based on thestrategy of the venue.

In one embodiment of the system allocating online bookings usingcustomer's information as part of the allocation algorithm.

In one embodiment of the system filtering products so that availabilityis only shown to certain customers concerning products, services,prices, times, durations and terms and conditions are only shown andmade available to certain customers and not to others. In one example,discriminating on the availability and offers to customers based on acustomer's ranking.

In a tenth aspect, one embodiment of the system the allocation of onlinebookings for travel, aviation, cruising, rail, coach, holidays, carrental and other similar activities and businesses whereby customersinformation is used in the booking and allocation process to offer amore personalised, more bespoke and more efficient service to customerswhile maximising the optimisation of quantitative and qualitativeoutcomes based on the strategy of the entity.

In one embodiment of the system allocating online bookings usingcustomer's information as part of the allocation algorithm.

In one embodiment of the system filtering products so that availabilityis only shown to certain customers concerning products, services, pricesand terms and conditions are only shown and made available to certaincustomers. In one example, discrimination the availability and offersbased on customer's ranking.

The Computing System

One embodiment of the computing system is shown at FIG. 2 a.

In FIG. 2a there is shown a schematic diagram of a computing system,which in this embodiment is a computing system 100 suitable for use withan embodiment of the present invention. The computing system 100 may beused to execute application and/or system services such as a computerprogram and an interface in accordance with an embodiment of the presentinvention.

With reference to FIG. 2a , the computing system 100 may comprisesuitable components necessary to receive, store and execute appropriatecomputer instructions. The components may include a processor 102, readonly memory (ROM) 104 , random access memory (RAM) 106, an input/outputdevices such as disc drives 108, remote or connected mobile devices 110(such as computers, smartphones or tablets and the like), and one ormore communications link(s) 114 including internet links to otherapplications, websites and system services including Internet cloudservices 120.

The computing system 100 includes instructions that may be installed inROM 104, RAM 106 or disc drives 112 and may be executed by the processor102. There may be provided a plurality of communication links 114 whichmay variously connect to one or more user devices 110, such ascomputers, smartphones or tablets, wherein the one or more user deviceshave a user interface for interacting with user by collecting anddisplaying data or information using the conventional means provided bysuch devices. At least one of a plurality of communications link 114 maybe connected to an external computing network through atelecommunications network, including Internet cloud services 120.

In one particular embodiment the device may include a database 116 whichmay reside on the storage device 112. It will be understood that thedatabase may reside on any suitable storage device, which may encompasssolid state drives, hard disc drives, optical drives or magnetic tapedrives. The database 116 may reside on a single physical storage deviceor may be spread across multiple storage devices, either locally orremotely.

The computing system 100 includes a suitable operating system 118 whichmay also reside on a storage device or in the ROM of the server 100. Theoperating system is arranged to interact with the database 116 and withone or more computer programs to cause the server to carry out thesteps, functions and/or procedures in accordance with the embodiments ofthe invention described herein.

The user interface 110 of one or more mobile devices facilitates thecollection and display of user data for the computing system 100. Theuser interface 110 may be a program or website accessed on a computer ormobile device via a communication network, such as the Internet.Alternatively, the user interface 110 may be a widget arranged on awebsite that may be accessed by a user using a computer or mobile devicevia a communication network such as the Internet. The user interface 110may also be provided as a mobile application or “app” present on theuser device, such as a tablet or smart phone.

The at least one user interacts with the user interface 110 and may be afirst user (also referred to as the “booking requestor”) requesting touse a space in a venue. The at least one user may also include a seconduser (referred to as the “operator” or “venue operator”), who isassociated with the venue and utilizes the optimised space allocationinstruction set provided by the allocation module to enable the use ofthe space by the booking requestor.

The booking requestor interacts with the computing system to make arequest. The requestor may make a request for one or more patrons of thevenue to use the space in a venue, where the requestor may also be oneof the patrons of the venue. That is, a user that interacts with thesystem is referred (on their own behalf or on behalf of a group ofpeople) is referred to as a booking requestor and the person (or groupof people) that will be allocated a table (i.e. attend the venue orrestaurant) may be variously referred to as the “patron” or “patrons”,the “customer” or “customers”, the “guest” or “guests” and/or the“diner” or “diners”, or any other term as appropriate for the venue.

An embodiment includes the computer system 100 processing the requestand undertaking all subsequent steps in an autonomous manner.Alternatively, in another embodiment, the operator may use one of theuser interfaces 110 provided to one or more devices to receive, input,or modify information in order to provide further input to the computersystem 100, so that the computing system may process the request andprovide instructions to the entity.

In processing the request, the computer system 100 may arrange objectsin the space in accordance with the optimised space allocationinstruction set. That is, the booking requestor acts as a customermaking a request which is to be “serviced” by the operator in accordancewith the optimised space allocation instruction set. As may beappreciated by a skilled addressee, there may be any number of remoteusers and operators who are able to interact with the computing systemvia the user interface 110 via any number of different devices.

Referring to FIG. 2b , there is illustrated in more detail the ResButlersystem in accordance with an embodiment of the invention. The ResButlersystem comprises a “back end” 2048 which is located in a cloud computingenvironment 2046 comprising an allocation system 2042 in communicationwith a security database 2040, a series of Venue databases 2058 (whichinclude venue constraint information and booking allocations). Bookingallocations are performed by an allocation system 2042 which includesone or more modules 2044, each module being arranged to apply specificallocation algorithms. In turn, a venue operator can access the systemvia a system web server 2056. The ResButler system 2048 provides access,on a remote device 2050, to a dashboard 2052 and a Point of Sale system2054.

Booking requestors may access the ResButler system 2048 via devices2060, 2066 and/or 2070. Device 2060 is a conventional computing systemor device arranged to utilise a web browser to access a venue website2062 which incorporates a booking widget 2064 Device 2066 is a mobiledevice, such as a smart phone, which is arranged to use an app 2068 toaccess the system. Device 2070 is an on-site “kiosk” device, whichincludes a kiosk app arranged to allow a requestor to access the systemvia the kiosk, for self-seating or to make a booking as a “walk-in”customer. Device 2070 may also be a mobile device such as a tabletcomputing device arranged to use app 2072.

The Computing Method

Turning to FIG. 2c , there is shown a flow chart of the processesundertaken by the computer system 200 to determine the optimalallocation of a user request to use a space. Firstly, a user makes arequest 202 which is collected by the user interface 204 on a device.Alternatively, the user 202 may access a third party booking site 211,which forwards information to an email parser 213.The input receivingmodule 206 receives a request from the user interface 204, where the atleast one user may be a customer making the request.

Alternatively, the at least one user may also be a service providinguser (a second user or operator), who is associated with the venue andmay provide information to the user interface 204 on behalf of anotherremote user. For example, the service providing operator, who may beemployed by the venue, may take a booking over the phone on behalf of aremote user. As would be readily understood by the skilled addressee,multiple user interfaces may be contemplated depending on whether theuse is an “outside” user such as a remote user or an operator, such asan employee.

The user input receiving module 206 transforms the data of the at leastone user's request into at least one string of request data and thencommunicates the request data to the optimisation module 208 via atelecommunications network. The request data includes all or part of theat least one user's request as collected by the user interface 204. Thatis, the at least one user's request may include a request for a timeperiod during which the space in a venue will be used, the number ofpeople who will be using the space, the contact details of the at leastone user making the request, the reason or occasion for the use of thespace, and whether there any special requirements to be made known forthe use of the space. The skilled addressee will appreciate that theuser input receiving module 206 may receive any data or information thatis set out by the user interface. That is, the user interface 204 may bearranged to collect any type of data provided by the remote user oroperator.

The at least one string of the request data is then received by theoptimisation module 208. The optimisation module 208 communicates withthe database 212, where the database contains stored data relating tothe request or any previously made requests. In an embodiment, thedatabase 212 stores the at least one string of request data prior toprocessing by the optimisation module 208. The stored data may alsoinclude any ancillary information (information not directly related tothe request) collected by the user interface and the user inputreceiving module. For example, the stored data may include at least oneother request to use the space which have been made by at least oneother user.

The stored data may also include past data, such as request data fromrequests made in the past, the details of the past use of the space, orthe amount of money spent during the use of the space. The computersystem 200 may provide the remote user with an option to open a useraccount or log into a previously opened account, which may be accessedby the user by means of a unique username and password as set by theuser. The account may be accessed by any mobile device connected to theInternet or a local network in communication with the computer system200. This enables the user to provide additional information to the userinput receiving module 206 which is stored in the database inassociation with that particular user, such as personal, financial, orother types of user information.

The computer system as described provides a real time service to theuser in processing their request. However, by providing the user with anaccount associates the user account with the request and allows the userto access the request where they may complete the request or modify thedetails of the request at any time after the request has been made.

The computer system as described, in one embodiment also generates realtime and forecasted plans of the space including the placement of thefurniture and objects which can be provided to the user by email orshown on their device such that a user can be provided instructions asto the location of the allocated table and directions on how to findtheir allocated table to “self-seat” themselves and minimise the cost ofsuch activity to the venue. The real time and forecasted floor plans arealso provided to the operator within the system application to assistthe operator in the planning, operation and management of the space,especially during the critical service period when time is critical andinstructions can be provided to an operator on how to reset tables forthe next booking.

Space Information and Constraints

The stored data in the database 212 may also include constraintinformation where the constraint information may include informationrelating to the space available for allocation within the venue. Thatis, the stored data may also include constraint information relating tothe venue itself, such as the spatial constraints of the space of thevenue, the ingresses and egresses of the venue, and the facilitiesavailable in the venue.

The stored data in the database 212 may also include sub-spaceconstraint information where the sub-space constraint informationincludes information regarding a sub-space within the venue. That is,the space may also include information relating to the at least onesub-space which is defined by the constraint information stored in thedatabase.

In other words, a venue may have sub-spaces of a space within a venue(within this application the terms space and subspace may beinterchangeable with the terms area and subarea respectively), where thesub-space constraint information relates to the limitations of thesub-space, including but not limited to, the physical dimensions of thesub-space, the shape or arrangement of the sub-space within the wholespace of the venue, and the maximum and minimum number of users able tobe accommodated in the sub-space, the amount or type of furniture thatmay be accommodated within the sub-space. The division of the entirespace that constitutes the venue into one or more sub-spaces may beundertaken for a number of reasons, such as but not limited to,providing speciality service or seating areas, child friendly zones,premium seating, or sectioning parts of the venue due to the physicalconstraints of the venue or the furniture contained therein.

In an embodiment, spaces and sub-spaces include sections within thespaces and subspaces of the space in the venue, such that theoptimisation module 208 performs an iterative allocation of requestsutilising the sub-space constraint information to optimise theallocation or use of sub-spaces within the space in the venue. Theiterative allocation of requests is performed by the processor 210,where the processor iteratively executes the steps of the algorithm andthe iterative allocation process using the user request data and theconstraint information stored in the database 212. The algorithmincludes a number of steps to determine the optimal use of the space—thesteps of the algorithm are described in more detail later.

In the embodiment where the venue is a restaurant, the restaurant mayinclude any number of spaces, sub-spaces or sections within therestaurant. The iterative allocation of requests to use the differentspaces, sub-spaces and sections may be optimised individually, or incombination with other sub-spaces, depending on the specific desiredoutcomes and the constraint information. For example, one space,sub-space or section may be arranged to maximise one particularvariable, such as revenue, where another sub-space may be arranged tomaximise another variable, such as patron satisfaction.

In an embodiment, the constraint information may also include objectconstraint information regarding at least one object arranged to beallocated to a space, sub-space or section, whereby the iterativeallocation of requests for spaces, sub-spaces or section may includeutilising the object constraint information to optimise the allocationof the objects within a space, subspace or sub-space in the venue. Thatis, using the object constraint information, the objects are optimallyarranged within the space or sub-space to maximise the chosen variable.

In an embodiment, the objects may include tables and chairs for dining.As is reasonably understood by a skilled addressee, there arepotentially an infinite number of variations to the types of tables andchairs that may be used for dining. As such, the objects may includesquare, rectangular, circular, elliptical or irregular shaped tables.Moreover, the objects may also include singular chairs or stools orshared seating such as benches. In a further embodiment the informationof which tables are interchangeable within a space, subspace or sectionwhich tables are fixed and which tables are flexible and can bepositioned in different spaces, subspaces and sections.

In an embodiment, the object constraint information may include the typeof object (for example, whether the object is a table or chair), theshape of the object, the physical dimensions of the object, informationregarding the ability of the object to interface with other objects(e.g. whether the object can be joined or arranged proximate to othersimilar objects), and a rating value that describes the relative qualityof an object (for example, the comfort rating of one type of chaircompared to other types of chairs). The constraint information may alsoinclude the dimensions of the object when arranged in a “compressed” or“folded” state when the object is in a storage configuration.

For example, the constraint information could be used such that thealgorithm is capable of identifying that a circular table cannot bejoined with a square table, or that a bar stool is not suitable seatingfor a standard height table. In other words, the constraint informationis utilised to determine which objects can be joined or placed proximateto one another in order to form a functional combination of objects. Forexample, the algorithm is able to determine that two square tables ofequal widths can be placed next to one another or joined in such a wayto form a single rectangular table.

The constraint information may also include information that allows thealgorithm to make comparisons between the relative utility of differentobjects, given a starting parameter which is to be optimised. Forexample, the constraint information can be utilised by the algorithm todetermine whether the removal of two round tables (each seating 4patrons) is a more suitable solution to the use of a single rectangulartable (or a combination of rectangular tables) within the dimensions ofthe space, sub-space or section to maximise a given parameter (such asseating the most number of guests within the dimensions of the space,sub-space or section).

In one embodiment the constraint information allows the algorithm tointerchange a different size table top for an existing table top tocreate a different seating outcome to accommodate a booking request orto maximise a given parameter. In the alternative, the algorithm alsopermits the removal of a table top placed on top of another table if itis not required for the subsequent re-use of the table.

In one embodiment the one or more spaces and subspaces within the venuerepresent fixed seating spaces where tables and other objects aretreated as fixed and cannot be moved. Within the defined spaces andsubspaces additional areas can be created which are referred to assections and the furniture and objects within sections are defined asflexible and can be moved. This allows the system to differentiatebetween objects that are fixed like a corner booth (which cannot bemoved or substituted) and loose objects like single unattached tablesthat can be moved to optimise for different requirements and outcomes.With flexible spaces the one or more algorithms can “push” tablestogether and join them, introduce additional tables, remove tables,replace tables with a different size and/or type of table, and replaceone table top with another or remove a table top from a table that hastwo table tops so as to optimise a given parameter such as theoptimisation of bookings within a section, subspace and space.

FIGS. 4c . 4 d and 4 e illustrate one embodiment of a venue floor plan401 which comprises a venue 470 which in the example includes two spaces472 and 474. Space 472 has been defined as the “Bar” and comprises onefixed table while space 474 has been defined as the “Main Dining Room”and comprises three subspaces; 476 defined as the atrium subspace, 478defined as the front room subspace and, 480 as the colonnade subspace.Within the atrium subspace 476 there are 4 sections 482, 484, 486 and494 which represent the flexible table areas where objects and tablescan be rearranged. In the front room subspace there are two sections 490and 492 while in subspace 480 there are no sections meaning all tableswithin that subspace are fixed.

Further, in one embodiment the constraint information includesinformation from the operator as to which spaces, subspaces and sectionsare open and information concerning which space or subspace to allocateand optimise bookings to first or if the entire venue should be treatedas a single optimisation process without ordering of the bookings to onespace or subspace first. Those skilled in the art will understand thatthe ordering and allocation process between different the differentspaces, subspaces, sections and the ordering of the optimisation processcan have practically unlimited permutations.

The constraint information may further include table numbers for easycommunication of table positions to users. In FIG. 4c table numbers arefirst referred to as locators or markers of a certain location with thevenue and applied in a way that provides easy communication as to wherea general relative location of the table relative to the venue and withreference to other tables. In FIG. 4c the colonnade subspace compriseswhat is referred to as the “ones”—that is, all table numbers which areassigned a number less than ten. Secondly, the front room subspace isreferred to as comprising the “tens to thirties” and the atrium subspaceis referred to as having the “forties to nineties”.

The constraint information may also include class information whereby aclass can include spaces, subspaces and sections and any combinationthereof. FIG. 4e comprises three different classes, namely “luxuryclass” denoted by 499 and 477, “premium class” denoted by 479 and 498and “standard class: denoted by 496, 481 and 483.

The allocation of numbers in this manner gives food runners an automaticunderstanding of where they are required to deliver food. At the secondlevel of the numbering system all fixed tables are given fixed tablenumbers within our numbering system. Flexible table areas, specificallyare only noted as the twenties or the thirties, etc. and the systemnumbers all additional tables within a section in numerical sequencestarting with the number 1 in that sequence, namely, 21, 31, 41 etc. asshown in FIG. 4c . The flexible table areas are generally referred to as“sections” and for more clarity are denoted by areas with dotted lineboxes (boundaries) generally denoted by 482, 484, 486, 494, 490, 492 and480 in FIG. 4d . The venue user also sets up the constraint within thesystem if the numbering system within a section should start from theleft, or from the right, or from the top, or from the bottom of asection. In the embodiment described herein, the numbering systemadopted does not use the numbers 10, 20 30, 40, etc. within a section asthe “ones” sequence does not have a zero and if two or more sectionswere parallel to each other the table numbers would not form a perfectgrid which would require additional thought to find a table.

The constraint information may further include patron identifiers, suchas, but not limited to, a unique seat or position at each table. Thisallows for specific identification of patrons and the particulars of therequest made to use the space. For example, when the request is made,the system may allocate each of the patrons to a position number, suchthat the patrons can preselect a menu item or items, drinks or any otherparticular aspect of their experience at the venue, and correspondingpay in advance for the experience, where the preselected items would beassociated with each position number. In a further embodiment there areprovided sensors at specific locations to identify the arrival and theseating of individual people at a specific position number at the tableas well as knowing when all guests have arrived and the table iscomplete. In one embodiment, the sensors may be located in a tableand/or chair. In another embodiment, sensors are provided at spacedapart locations within the venue, wherein the sensors are capable oflocating individuals within a particular space.

That is, the embodiment offers a real time complete service for thebooking requestor optimally arranging the layout of the restaurant toseat the requestor, receive their order, deliver their order, includingproviding self-seating and payment facilities, and thereby manage theentire experience at the venue.

As such, the embodiment provides the requestor with the ability toreview or modify the details of the request. For example, if therequestor is associated with the venue (e.g. they have registered withthe venue), the requestor may review or modify the details of theirrequest after the request has been made by accessing their account.Alternatively, if the requestor has no previous association with thevenue, the requestor may be provided with a unique reference number (orother identifier such as a QR code) to identify the request, and therequestor may use the identifier to review or modify the details of therequest and the subsequent allocation.

Moreover, the constraint information may further include statusinformation relating to the booking requestor. The embodiment providesthe ability for requestors to interact with the user interface 204 andregister identifying information which is saved by the database andallows the requestor to subsequently interact with the system(colloquially referred to as “becoming a registered member” of thevenue), wherein the requestor is provided with a personal “account”storing past request information and more detailed requestor constraintinformation, wherein the past request information is utilised as furtherconstraint information for all subsequent booking requests. The statusof each requestor (and also each person associated with the requestor)is stored in the database in a secure manner in accordance with knownmethods for securing sensitive and private data.

For example, a requestor that is identified by the venue to be a “VeryImportant Person” (VIP) is allocated a higher ranking compared to arequestor who is not a VIP. Where a ranking system is employed for allrequestors, requests to use a specific space, sub-space, section ortable may be preferentially allocated to a booking requestor based onthe status of the requestor. Moreover, the requestors within eachcategory of “status” has an individual ranking within the correspondingstatus ranking. That is, the request of requestor identified as a moreimportant VIP will be prioritised over a requestor identified as a lessimportant VIP when allocating a request to use a space, sub-space,section or table. The ranking of a requestor may be determined by theowner of the venue or by the at least one user associated with thevenue. In the embodiment described herein, the ranking also includes thecategory of “Super VIP”, which includes requestors who are ranked higherthan a VIP. However, it will be understood that the categories describedherein are provided by way of example only, and act as “labels” to allowcategorisation. No gloss should be taken from the labels utilised tolimit the scope of the embodiment or the broader invention described anddefined herein.

Additionally, the embodiment may access one or remote databases orwebsites which contain news or popularity data (for example a measure ofthe popularity of search or recently viewed news or information such ashttps://trends.google.com.au/trends/) to determine a ranking or promptthe embodiment to update a requestor's ranking.

Moreover, the venue constraint information may include information thatallocates a ranking to an section, subspace or space. That is, one ormore spaces, sub-spaces, sections or classes may be allocated a rankingbased on the attributes of the space. For example, a sub-space thatincludes a desirable view, which would be understood to enhance theexperience of the requestor using that sub-space, would be considered tobe a “premium” sub-space. Other attributes that form part of the venueconstraint information can include the comfort of the furniture in thesub-space, the space between tables, or any other relevant physicalcharacteristics of the space, sub-space or section.

Correspondingly, the range, quality or price of the menu items, thenumber of courses offered for the sub-space or the quality of service byusers associated with the venue are constraint information that fallunder the “class” classification. In other words, the “class”classification encompasses constraints that are not directly related tothe physical space, but to constraints that are more relevant to theservices offered at the venue.

It will be understood that in a venue, some of the objects to beallocated to a space or sub-space may be permanently fixed in theirposition. Such objects may include booths or seating at a bar.Accordingly, in the embodiment, the descriptors “space” and “sub-space”refer to areas within the space where the venue constraint informationincludes information indicating that the objects are either unable to bemoved and are considered “fixed objects”, or alternatively, that theobjects can only be moved in very limited ways. For example, a fixedtable may be modified by the addition of a different table top but maynot be swapped for a different table.

Correspondingly, the objects to be allocated to a section can be moved,removed or combined with other objects. In an embodiment, the venueconstraint information specific to sections includes informationindicating that the objects in the sections are able to be moved.Therefore, the objects within the sections can be arranged into manydifferent permutations enabling potentially limitless objectarrangements that may be allocated to a section. It is the ability to“map” a particular arrangement of furniture within a section that, inpart, enables the use of the space to be optimised to accommodate userrequests.

The limit of the number or type of objects that can be allocated to aspace is determined by the dimensions and shape of each object and theconstraint information included that defines the dimensions and shape ofeach section. In other words, in an embodiment, the venue constraintinformation also includes object constraint information regarding thedimensions of one or more tables, chairs and/or any other objects thatare locatable within each section. As such, there is no requirement forthe venue to “provide” a restaurant layout, except for areas whereobjects are fixed.

The constraint information can further include information that allowsfor the identification of each object through the use of uniqueidentifier mechanisms, such as an identification number or an embeddedRadio Frequency Identification (“RFID”) chip with a unique number orcode to enable the identification of specific objects. The constraintinformation may also include information on the status of the object,for example, whether the object is currently positioned in the space oris in another space (or in storage), whether the object is in use or notin use, and whether the object is optimally arranged or has beenarranged manually. That is, the embodiment may also include one or moreRFID sensors (or other sensors that allow the position/location of anobject to be determined relative to the dimensions of the space)arranged in the space such that the embodiment receives live data fromboth the RFID sensors and chips to determine whether the object has beenoptimally arranged in the space subject to the optimised spaceallocation instruction set.

The constraint information can further include information relating tothe dimensions or capacity of the storage space. Such information mayinclude the dimensions of objects in a stored state within the knowndimensions of the storage space to determine the capacity of the storagespace for storing objects. Alternatively, the capacity of the storagespace may be provided by reference to the specific number of items thatmay be stored in the storage space.

The venue constraint information can further include informationrelating to the service period during which the space, sub-space orsection is utilisable. Accordingly, the venue constraint information caninclude information relating to the division of a use of the spaceacross discrete service periods (also commonly referred to as “seatings”in the restaurant industry) where the service period is initially set.The venue constraint information can also include meal periods, whichdescribe the amount of time required to service menus of differentcourse sizes and complexities. In the example of a restaurant, a mealtime “unit” would be determined by the time taken by a restaurant patronto consume a meal consisting of a single course, including seating timeand “re-setting time”. By quantizing the meal time in this manner, thetime utilisation of a particular space, sub-space or section isoptimisable across the operating time of the space, sub-space orsection.

Further, as would be appreciated by the skilled addressee, the storeddata in the database may include historical information relating to pastuse of the space in a venue which can be used to optimise average mealtimes allowed or allocated to a booking request.

The venue constraint information may also include information relatingto external factors that have an impact on the venue. External factorscan include, for example, events related to particular times of theyear, such as, but are not limited to, the day of the week, publicholidays, festivals, school holiday periods, conferences, proximatesocial or religious events, or past, current or predicted futureweather. The person skilled in the art would understand that the venueconstraint information may include any variable external to the venuethat affect the operation of the venue, even if the relationship islatent or indirect. The optimisation module 208 may utilise one or moreof the external factors as a factor in the optimisation of the operationof the venue or may also utilise one or more of these factors in apredicting and forecasting functionality, which is described in furtherdetail below.

Optimisation Module/Algorithms

In an embodiment, the optimisation module 208 uses the processor 210 toquery the database 212 to determine whether other booking requests forspaces have been made by other requestors, wherein booking requestsincludes unallocated requests, previously allocated requests, requestson a wait list and requests on hold. If booking requests are identifiedon the database 212, the optimisation module 208 utilises the processor210 to retrieve the requests in the database 212 and combine the atleast one request with the other requests to form a pool of requests.The optimisation module 208 also utilises the processor 210 to retrieveother relevant venue constraint information from the database 212. Thereare also provided Book Restaurant Forms 203 and Book Function forms 205.An external portal 218 allows the venue operators to access “back end”functions and provide or edit venue constraint information.

The optimisation module 208 uses the processor 210 to iterativelyallocate all requests from the pool of requests utilising the venueconstraint information and the requestor constraint information. Allrequests in the pool of requests are allocated to produce an optimisedspace allocation instruction set 214, in accordance with the venue andrequestor constraint information. That is, with each new request, allprevious allocations that have been determined become past optimisedspace allocation instruction sets. The past sets are saved in thedatabase 212. With a new request, all previously accepted requests inthe pool of requests are iteratively re-allocated to produce a newoptimised space allocation instruction set that includes the currentrequest.

Each new optimised space allocation set 214 that is generated by theallocation module 208 is saved in the database 212, which may alsoaccess external web data 215, and may utilise other modules includingResButler Applications 217, ResButler Processes 219 and External Systems221. The computing system 200 further includes a space allocation userinterface 216, which is in communication with the database 212. Thespace allocation user interface 216 displays at least one optimisedspace allocation instruction set 214 to one or more operators associatedwith the restaurant 218. The optimised space allocation instruction setmay be represented on the user interface of the restaurant 218 as aninteractive digital scaled-map representing the position of specificobjects, such as tables, and the arrangements and combinations of thoseobjects within the space. The interactive digital scaled-map may bemodified by one or more users associated with the venue. Alternatively,the optimised space allocation instruction set may be generated as animage, Gantt chart, documented instructions or any other manner ofrepresentation that illustrates to an user the optimised arrangement ofobjects in a space.

The allocation module 208 may also include a predicative module 220 thatallocates booking requests at least in part on the historical datastored in the database 212. The predicative module 220 utilises theprocessor 210 to predict an optimised space allocation instruction setbased on past data using regression analysis techniques or any othermathematical algorithms which identify relationships between pastdependant and independent variables and match them to current variabledata to extrapolate an optimised space allocation instruction set toaccommodate the at booking request.

For example, where the venue is a restaurant and the computer system 200has received a request for a particular day, such as Valentine's day,the system 200 can review historical optimised space allocationinstruction set data from past Valentine's days and determine that theprior optimised space allocation instruction sets comprised primarily oftables of two. The predictive module 220 communicates with the processor210 and the database 212 to provide the allocation module 208 with thedata necessary to determine an optimised space allocation instructionset in accordance with the historical data. This set may be used by theoptimisation module 208 as the first optimised space allocationinstruction set generated for the first request received for that use ofthe space of the venue.

In an embodiment, the predictive module 220 may also be used foroptimising the use of resources in a restaurant or venue, where thepredictive module 220 uses the processors 210 to accesses historical andlive data regarding the use of the resources of a restaurant stored inthe database 212. The predictive module 220 also accesses theinformation regarding the actual usable resources at any given period oftime collected by the user interface 218. The predicative module 220utilises the optimisation module 208 and processor 210 to analyse thehistorical and current “live” data and the actual usable resource dataand determine the relative optimal use of the usable restaurantresources for the any given period of time using a yield determinationalgorithm, or any other similar deterministic algorithm.

For example, the predictive module 220 may access historical and livedata and usable resource data and determine the number of staff likelyto be required for the next service period for the venue.

In an embodiment, the predictive module may further be utilised tosimulate the operation of a venue prior to receiving live bookingrequests. The predictive module allows the venue operator to manuallyfix particular venue constraint information variables (such as the totalnumber of guests per service period, service period duration times,constraint information relevant to specific occasions, different menus,different courses, different allocated menu and course duration times,discrete and overlapping service periods, etc.) to derive one or moresimulated optimised space allocation instruction sets. Using the one ormore simulated optimised space allocation sets, the venue operator candetermine the ideal number of objects and other variables which willoptimise the yield (such as the amount and types of tables and chairs,the menus offered, etc.). The simulation capability offers a substantialimprovement over the current method of setting up a venue by guessing ortrial and error of the arrangement of a venue.

The allocation module 208 may further provide information regarding oneor more resource parameters that may be optimised to increase the yieldof the restaurant. The optimisation module 208 may also user thepredicative module 220 to utilise the yield determination algorithm orthe historical data to forecast future demand for the resources to setcapacity, menu, pricing, and service constraints, as well as tocalculate resource requirements such as, staffing requirements, foodcosts, ancillary costs, rental costs, maintenance costs, and capitalcosts. The yield optimisation may be provided as instant feedback to oneor more venue operators, where the feedback may be in the form of anautomatically generated report, which may include either static orinteractive tables, graphs or other graphical tools or used toautonomously adjust the constraints of the embodiment.

Referring to FIG. 2e , there is displayed a example of the applications217, the web portal applications 228 and the processes 219 in accordancewith an embodiment of the invention.

In particular, the ResButler applications 217 includes online menus 222,pre-ordering decision tree 224 and kitchen printing app 226. The webportal 204 includes the booking app/widget 230, the self-seating app232, a functions app 234, a home delivery app 236, a takeaway app 238and a gift certificate app 240.

Moreover, in terms of “back end” functions, the ResButler systemincludes a number of processes 219 arranged to interrogate the database256 for yield management 242, point of sale 244, staff rosters 246,supplier information 248, purchasing information 250, financial andother reports 252 and forecasting reports 254.

Referring to FIG. 2f , the ResButler System also includes access to anumber of external systems 221 including an external CRM 258, anexternal payment gateway 260, links into external accounting systems 262and external point of sale systems 264. Moreover, the ResButler systemis arranged to receive web (or external) data 215 of different types,including weather 266, social media 268, public holiday information 270,local event information 272 and special day information 274. This datamay be received as a direct “feed” using an API or similar connection,or may be “scraped” from a website, depending on the type of data andthe source. Such variations are within the purview of a person skilledin the art.

As discussed above, the embodiment 200 discloses a system for optimisingthe use of space in a venue. It will be understood by the skilledaddressee that the computing system 200 is applicable to any use wherespace is to be allocated. For example, optimising space in a venue wherethe venue may be a restaurant, bar, café or any hosting venue offeringthe use of a space where the arrangement of the objects impact theoptimisation or desired outcome of the space.

Moreover, the system may also be used for optimising the use of space ina venue where the venue is an entertainment venue such as a concert,cultural or a sporting event where the arrangements of the objectsimpact the optimisation outcome.

Moreover, the system may also be used for optimising the use of space ina venue where the venue is a workspace or function or event space venueor hotel or accommodation venue where the placement of objects canoptimise and improve an outcome.

Alternatively, the system may also be used for optimising the use of“time” in areas where products or services have different revenue andmargin impacts, and the products can be offered at different times withdifferent constraints to optimise desired outcomes. For example, ahairdresser could offer “hair colouring” only at off peak times as aperson may be occupying a seat for a very long time when it may havebeen used for two haircuts which could have yielded more revenue andmargin for that seat. Alternatively, a car park could offer a minimum 2hour parking time slot during peak periods and a half hour minimumparking time slot during non-peak periods. As another example, in a fastpaced casual restaurant model with orders entered online, the system canallocate the customer to a particular table with directions on how tolocate the table as well as giving the customer a fixed time to consumetheir meal (such as half an hour) to ensure that customers do not “hog”tables or “spread themselves out” taking more chairs or tables than theyneed.

System Flowchart

Referring now to FIG. 2g , there is shown a series of modules/componentsand method steps, for the embodiment described herein, alongside acomparison with a prior art system, which is utilised to provide contextwith regard to the differences between the embodiment and the prior art.Numerals on FIG. 2g correspond with numerals on following FIGS. 2h to 2m. Therefore, any reference to modules, components and/or method steps inFIGS. 2h to 2m are equivalent to the reference numerals found in FIG. 2g.

Referring to now FIGS. 2j to 2m , there is shown a diagrammaticrepresentation of each of the component parts of the system inaccordance with an embodiment of the invention. The following referencesare provided as a summary of the information referred to within the flowchart:

-   -   1a Restaurant Set-up Rules: Open/closed; Meal periods; Primary        Floor Plan to scale; Alternative Floor Plan Constraints to        scale; Rooms, Areas, Subareas, Sections, Bars to scale;        Dimensions, storage, furniture; Seat block-outs; etc. (278)    -   1b Menus: Pre-theatre; Post-theatre; A la Carte, breakfast,        lunch, dinner, supper etc.; By group size; By time; etc. (280)    -   1c Dynamic Pricing and Dynamic Product and Service Promotional        Offers: Extended Time Duration Pricing; Shortened Duration        Discounted Pricing; Promotions by Time, Group Size, Menu,        Course, Day of the Week (282)    -   1d Special Events Scheduled by Venue: Family Day etc. (284)    -   1e CRM: VIP details; VIP offers; Member history; Member ranking;        etc. (286)    -   1f External Websites: Celebrities, etc. (288)    -   1g Forecasting and Predictive Model: Booking times; Booking        capacities; Booking classes; Staffing forecast; Resource        forecast; Operational forecast, etc. (290)    -   1h Suppliers: Orders; Deliveries; Constraints, details etc.        (292)    -   1i Database of Booking Requests: Utilised in the iterative        booking allocation optimisation (294)    -   1j Optimisation Quantitative and Qualitative Strategic Rules and        Outcomes: Floor Space Optimisation Algorithm; Time Related        Optimisation Algorithm; Event Related Optimisation Algorithm;        Strategy Related Optimisation Algorithm; Third-Party        Optimisation Algorithm; Pre-service Optimisation Algorithm;        In-service Optimisation Algorithm; Self-Seating Optimisation        Algorithm (296)    -   1k Resource Parameters: Venue set-up times; etc. (298)    -   1l Reporting: Performance analysis; Customer satisfaction;        Deliverables; Labour Analysis; Actual v. Predicted etc. (231)    -   1m Database Historical Information: Booking duration times; Time        bookings made; Classes of bookings; Spend by booking types;        Yield; Efficiency; Walk-ins etc.; etc. (233)    -   1n External Websites: Weather (235)    -   1o Printed Operational In-Service Run Sheets (237)    -   1p Operational Requirements and Planning: Staffing levels;        Rosters; Start/Finish times; Orders; Delivery Schedule; etc.        (239)    -   1q Point of Sale Integration: Dynamic Floor Plans; Seating;        Orders; Payments; Sale items; Etc.; CRM details (241)    -   1r Stock Control, Ordering and Purchasing (243)    -   1s Home Delivery and Takeaway Integrations for Production and        Time Scheduling (245)    -   1t Payment Rules: Payment Decision Tree; Prepayment and payment        constraints (247)    -   1u Artificial Intelligence: Including data mining, advanced        analytics, modelling and predictive analysis to automatically        amend constraints. (251)    -   1v Alternate Payment Systems(253)

Referring to FIGS. 2j to 2m , the following references are provided as asummary of the information referred to within the flow chart as “ClaimedInvention” 276, “Intuitive booking allocation super highway” (297) andbooking allocation information 2026:

-   -   2a User (255)    -   2b Various Access Channels (257)    -   2c User/User Interfaces: Restaurant Booking Widget, Function        Booking Widget, Self-seating Kiosk, Self-seating App, Restaurant        Booking App, Menu Pre-ordering App/Widget, Promotional        Apps/Widgets, Booking Form. (259)    -   2d User requirements used in the Booking Allocation: (Claimed        Invention) Buy a specific table, request a specific table,        request an extended dining duration, Flowers, Chocolates, Card,        Entertainment, Gift, Different order of service, Personal        Waiter, Specific Personal Waiter, Budget, Occasion etc. (261)    -   2e Strategic Control of Capacity, Product and Services for        Booking Allocations: (Claimed Invention) Strategic capacity        availability by Area, Sub-area, Section and Class. Strategic        Product and Service Availability by Menu, by Courses, by        Variable Time Durations to meet revenue and yield management        targets. (263)    -   2f Booking Allocation for the Optimisation of Space: (Claimed        Invention) Sale of specific tables with guaranteed allocation,        Super VIP guaranteed seating, VIP prioritised seating,        Optimisation of remaining table allocations to Area, Sub-areas,        Sections and Classes based on venue strategy.(265)    -   2g Payment/Deposit Confirmation (267)    -   2h Butler Service: Ordering of 3^(rd) Party Services/Products.        (271)    -   2i Time-Related Booking Optimisation: At a predetermined time        (e.g. 1 hr before service), reallocation to offer the best        tables to the highest ranking, non-guaranteed table-allocated        customers (Musical Chairs) (269)    -   2j Event-Related Booking Optimisation: At the occurrence of an        event, e.g.: Rain, reallocation of outdoor bookings to tables in        undercover Areas, Sub-areas, Sections and Classes. (273)    -   2k Capacity-Related Booking Optimisation: In the event that a        particular class of table is at full capacity, a determination        if demand for other classes of tables is such that they can be        reduced and additional tables offered for the class in demand.        (275)    -   2l Strategy-Related Booking Optimisation: Ambience        re-allocation: if restaurant is not expected to fill up or other        parameters apply. (277)    -   2m Third Party Information Booking Optimisation: Theatre        information, website information which may have an impact on        capacity decision. E.g. allocating bookings to a minimum space        in anticipation of a full theatre next door. (279)    -   2n Pre-service Booking Allocation Optimisation: Final        optimisation before service taking all the above factors into        account, as well as opening up capacity for walk-ins, if such        capacity had been previously excluded from the allocated        capacity. Creation of run sheets and service notes for staff. If        a venue selects self-seating option, floor plans and seating        locations as they would appear at time of arrival of each        booking are sent to each customer. (281)    -   2o Cockpit Dashboard: Dynamic Floor Plan; Time-based floor plan        (283)    -   2p In-service Booking Allocation Optimisation: Optimisation can        be based on any combination of the above optimisation algorithms        or different algorithms which can only use tables located within        the restaurant and/or without moving pre-allocated bookings        and/or allocating bookings based on space optimisation or other        dimension such as allocation to the best table. (285)    -   2q Self-Seating Kiosk (Booking Allocation): Applicable for        venues that have selected the self-seating option. The kiosk can        provide information on the seating location of confirmed        bookings as well as the ability of accepting new walk in        bookings. (287)    -   2r Autonomous Restaurant and Complete Integration: Fully        integrated information system including table and position        sensors. (289)    -   2s Point of Sale System: Fully integrated with dynamic real-time        table plan layout with orders sent to kitchen and bar as        appropriate. (291)    -   2t Payments: Fully integrated with links to original booking        including part payments by table, customer and position number.        (293)    -   2u Accounting System: Revenue; P&L (295)

Referring to FIGS. 2h to 2i , the following references are provided as asummary of the information referred to within the flow chart as “PriorArt” 223, “Reactive Allocation” 2030 with booking allocation information2032:

-   -   3a User (2000)    -   3b Access Channels (2002)    -   3c User/User Interfaces: Restaurant Booking Widget, Booking        Form. (2004)    -   3d User requirements used in the Booking Allocation: (Prior Art)        Date, time, meal period, pax (2006)    -   3e Strategic Control of Capacity, Product and Services for        Booking Allocations: (Prior Art) Capacity and Max Group Size by        booking time interval for a standard time duration.(2008)    -   3f Payment/Deposit Confirmation (2010)    -   3g Allocation of Booking Request: (Prior Art) Use of a        prioritised list of tables and table combinations to allocate        bookings. Prior Art process finishes with this step. (2012)    -   3h Dashboard: Static Floor Plan (2014)    -   3i Payments (2016)

Referring to FIG. 2h and FIG. 2i , the following references are providedas a summary of the information referred to within the flow chart as“Prior Art” 223, “Booking Allocation Information” 2032:

-   -   4a Restaurant Set-up Rules: Open/closed; Meal periods; Floor        Plan (not to scale); Seat block-outs; Rooms, Areas, Bars; Tables        and table combinations prioritised list; Standard booking time        duration (2020)    -   4b Promotional Offers: Discount by time interval (2022)    -   4c Database: List of unused tables and table combinations (2024)

Referring to FIGS. 2h and 2i they provide a diagrammatic representationof each of the component parts of the prior art.

Referring to FIG. 2j to FIG. 2m , the following description is providedas a summary of the overarching algorithms contained in the embodimentillustrated.

It will be understood that the description with regard to FIG. 2j toFIG. 2m are not to be taken as an exhaustive description of theinvention or embodiment, but rather a summary of an embodiment, toenable a person skilled in the art to gain an understanding of thebroader inventive concept. It will be understood that the subsequentFigures will describe some of the algorithms in more detail and willprovide examples of reduction to practice. That is, the description withregard to FIG. 2j to FIG. 2m are not to be taken as evidence that theinventive concept is “abstract” or the mere implementation of anabstract concept. Rather, the description of FIG. 2j to FIG. 2m isintended as a primer or high level view of the underlying inventiveconcept, to enable the person skilled in the art to better understandthe inventive concept.

It will be understood that the description with regard to FIGS. 2j to 2mare not prescriptive in that all algorithms are required to be taken ortaken in the order that they are shown the description or that they forma definitive list of steps and algorithms possible. The purpose of FIGS.2j to 2m is to highlight the inventive concept of using the knowledge ofspace, objects and their relativity and utility in the optimisation of aspace based on the strategic parameters or constraints of a venue.

Moreover, there will be described below a series of algorithms, whichfor convenience, are numbered. However, it will be understood that eachalgorithm is independent, and the numbering is not reflective of anyspecific order in which the algorithms are to be applied. The embodimentmay apply one or more algorithms dependent on constraint information.

The First Algorithm is termed the “Strategic Capacity Control”algorithm, module 263, (2e) which makes an assessment of requests basedon availability with reference to allocations by space, subspace, class,by time, allowing capacity for walk-ins, by menu, by course, etc.

The Second Algorithm is termed the “Optimisation of Space Outcomes”module 265, (2f) and is relevant to guaranteed table allocations. Thealgorithm which is an iterative seating optimisation algorithm which isarranged to allocate seating first to Super VIP's and guaranteed seatingallocations then based on availability by VIP, group size, etc., tooptimise the allocation and position of tables. This algorithm isarranged to optimise floor space efficiency around guaranteed tableallocations.

The Third Algorithm is termed the “Time Related Optimisation” algorithm,module 269, (2i) which is best described by an example. For example, onehour before service, if it is decided that no new tables should beadded, all bookings are reviewed, and, if there are two differentbookings at 6 pm and one booking is from a regular customer and one isfrom a first time visitor, the regular customer is allocated to thebetter table and the first time customer is allocated to the othertable.

The Fourth Algorithm is termed the “Event Related Optimisation”algorithm, module, 273, (2j) which is triggered or undertaken by theoccurrence of an event. For example, if it rains, the algorithm wouldre-allocate part or all of the bookings to outside tables to insidetables as all or part of the outside tables may be rendered unusable.

The Fifth Algorithm is termed the “Full Capacity Optimisation”, module,275, (2k) which is triggered or undertaken when one space, subspace, orclass is full. For example, if a specific class within the restaurantwas full the algorithm would evaluate if demand for the other classesfor that service had availability. If other classes had availabilitythen it would determine if those tables would be filled and what therevenue and contribution would be and if it then determined that itwould be best to increase the size of the class that was full and reducethe seating availability in another class it could do so and increasethe capacity within the class for which the booking request was receivedand allocate the booking request against one of the additional tablescreated in the expanded class.

The Sixth Algorithm is termed the “Strategy and Ambiance Optimisation”,module 277, (2l) algorithm. All bookings are reviewed, and if it isfound that the restaurant will not be at capacity, the bookings arespread around the restaurant so that a better ambience is achievedwithin the restaurant. For example, if a restaurant only has twobookings for a Monday evening, the Second Algorithm may have sat bothbookings next to each other in a back corner of the restaurant as thiswas the most efficient use of the restaurant space. This algorithmrecognises that this arrangement is not an ideal seating arrangement foran empty restaurant and allocates the two bookings in this example togive both bookings the two best available tables.

The Seventh Algorithm is termed the “Third Party InformationOptimisation”, module 279 (2m) algorithm. For example, the optimisationalgorithm could access third party information such as the bookings forthe local theatre and the start and finish times of a show to determinecapacity allotments and constraints. Further, it can determine not tooffer discounts or promotions at 9 pm as the theatre will finish and itexpects numerous walk-in customers.

The Eighth Algorithm is termed the “Pre-Service Quantitative andQualitative” algorithm, module 281, (2n). This is the final optimisationalgorithm before a service and can be a combination of one or more ofthe previous algorithms at the discretion of the restaurant manager. Itis run at a predetermined time before service and is also used to createrun sheets and provide information to restaurant staff as well asprovide final seating plans and arrangements for self-seating customers.As another example, as a restaurant can be split into different classespart of a restaurant can offer self-seating and part of a restaurant canoffer full table service.

The Ninth Algorithm is termed the “In-service Allocations withoutadditional tables or changing existing table allocations” algorithm,module 285, (2p). This algorithm is executed after service begins andnew bookings are limited to the use of only tables physically availablewithin the restaurant. The in-service optimisation process uses theIn-service Allocations algorithm to provide a limited optimisationprocess which limits the allocation process by means of additionalconstraints to optimise request allocation process with minimise thedisturbance to current patrons.

The Ninth Algorithm is not mandatory as the eighth algorithm or anyother algorithm or a combination thereof could continue to be usedwithout the need to unseat existing bookings whilst maintaining theability to add or remove one or more tables.

The Booking Process

Referring to FIG. 3, the iterative allocation process 300 may beperformed by the processor performing a number of steps that determineswhether a request can be accommodated given any previous remote userrequests that are stored on the database and in accordance with theconstraint information. The process 300 may include the following steps:

-   -   Step 1 shown at 302: The requestor creates and submits a booking        request for a venue via one of the multiple booking channels.    -   Step 2 shown at 304: The system can identify the booking request        information, retrieve information to classify requestor        identity, ranking, history, table preference, if they will be        granted guaranteed seating, and uses this information together        with the space and venue constraint.    -   Step 3 shown at 306: The booking request is then pooled together        with all previous requests which are still active for that        service, including requests placed on a waitlist or any other        active list.    -   Step 4 shown at 308: All booking requests are attempted to be        allocated in accordance with the optimisation algorithm applied.    -   Step 5 shown at 310: The last received booking, as it has been        defined as a guaranteed table allocation is allocated to the        prescribed table and the booking requestor is notified that        their booking has been accepted.    -   Step 6 shown at 312: All previously received bookings as well as        the last received booking could be allocated to a table and the        booking requestor is advised that their booking request has been        successful.    -   Step 7 shown at 314: All previous booking requests as well as        the last booking request could not be allocated a table so the        last received booking request cannot be accepted.    -   Step 8 shown at 316: The system calculates all alternate booking        times which can accommodate the booking request, as well as        shortened durations and alternate options including incentives        for the booking requestor to consider and accept the alternates        suggested. The booking requestor is also given the options of        joining a waitlist or to cancel their request.    -   Step 9 shown at 318: The booking requestor accepts one of the        alternate options offered, the system then accepts the booking        and the booking process is completed at 324.    -   Step 10 shown at 320: The booking requestor accepts to join the        waitlist and is placed on the waitlist. The booking requestor        remains on the waitlist until an allocated booking is amended,        cancelled, a new booking is received or other action is taken        for that service when system will trigger the algorithm to        reconsider and see if the waitlist booking can be allocated to a        table. If the waitlist booking can be subsequently be allocated        to a table an email and/or message will be sent by the system to        the booking requestor to confirm that they would still like to        go ahead with the booking. At some point prior to the        commencement of the service, at the time inputted by the venue        the booking requestor will be advised that their waitlist        booking will be cancelled as they have been unsuccessful for        that service and offering the booking requestor an alternative.    -   Step 11 shown at 322: The requestor decides that they do not        wish to accept and alternate time or alternate conditions and        they do not wish to be added to the waitlist and they cancel        their booking request.    -   Step 12 shown at 324: The booking request is allocated, and        forms part of the optimised allocation instruction set, which is        subsequently displayed on the user interface to the venue        operator.

As can be appreciated by a skilled addressee, the above steps may bere-arranged or varied to optimise certain objectives for the use of thespace. Alternatively, the above steps may also be repeated or variedover certain temporal periods. For example, the steps may be re-arrangedor varied for each service period, meal consumption period, etc.,allowing certain periods to overlap at different tables as determined bythe venue operator or as may be requested by a booking requestor. Forexample, during non-peak sittings, the venue operator may vary the stepsto enable requestors to self-allocate the use of the space. However,during peak sittings, the venue operator may vary the steps so that theuse of the space would be allocated only by the system ensuring that allallocations are optimised.

Optimisation Steps

In an embodiment, during the performance of FIG. 3, Step 4, 308, theprocessor may also include different algorithms, rules and subroutinesto arrange the objects in the space, sub-space or class as shown in FIG.4a . The subroutine 400 may include the performance of the followingallocation and optimisation steps:

-   -   Subroutine step 1 shown at 402: Pooling of all booking requests        including waitlist booking requests for a space and sorting the        bookings in order of allocation complexity starting with the        largest size metric (number of guests multiplied by the meal        duration time) and the most difficult metric (booking size        metric of the booking request that overlaps a peak period or        nearest to a defined peak demand period, wherein a service        period can have more than one peak demand period).    -   Subroutine step 2 shown at 404: Select the largest and most        difficult booking request metric and the first defined priority        space or subspace (in an attempt to provide a clearer example of        the optimisation steps the complexity of Super VIP's, guaranteed        table allocations, classes and other allocation permutations        have been excluded from this example which are discussed in more        detail later within this application) and attempt to allocate        the largest most difficult booking request metric to a fixed        table that perfectly matches the maximum seating capacity of        that table. If booking request can be allocated then next        booking request from the pooled booking list to be allocated        further, if the first priority space or subspace becomes full        then the nest priority space or subspace is to be utilised. In        the event that the booking request cannot be allocated then move        to step 406.    -   Subroutine step 3 shown at 406: Allocate the largest and most        difficult booking request metric to a fixed table that meets the        minimum number of guests permitted on that table and does not        exceed the maximum number of guests for that table. If booking        request allocated back to step 404 or move to step 408.    -   Subroutine step 4 shown at 408: Allocate the largest and most        difficult booking request metric to a flexible table that can        perfectly match the size of the booking request meets the        maximum number of guests permitted within that flexible space.        If booking request allocated back to step 404 or move to step        410.    -   Subroutine step 5 shown at 410: Allocate the largest and most        difficult booking request metric to a flexible table that        represents the smallest flexile space to which this booking can        be. If booking request allocated back to step 404 or move to        step 412.    -   Subroutine step 6 shown at 412: Allocate the largest and most        difficult booking request metric to a combination of more than        one fixed and or flexible tables that represents the smallest        floor space to which this booking can be allocated. If booking        request allocated back to step 404 or move to step 414.    -   Subroutine step 7 shown at 414: Allocate subsequent booking        requests by clustering around larger booking requests. If        booking request allocated back to step 404 or move to step 416.    -   Subroutine step 8 shown at 416: Where a booking request cannot        be allocated allocate it on top of the smallest best fit        subspace and then add all displace booking requests to the        original pool of requests and back to step 404 or move to step        416.    -   Subroutine step 9 shown at 418: Where all attempt to allocate a        booking request have failed then review alternate floor plan        constraints to determine if an alternate set of floor plan        constraints would permit the allocation of the booking. If final        booking can be allocated notify the user making the last booking        request that their booking has been successful or offering        alternative booking options as shown in 316, 318, 320 and 322.

Dynamic Floor Plan

With reference to FIG. 4b , in one embodiment the computing systemincludes a floor plan that comprises a standard floor plan 421 withstandard dimensions of length 424 and width 422 on a two dimensionalaxis. The third and volumetric axis is a representation of time 426.

In one embodiment the “volumetric floor plan” 421 is updated in realtime each time a booking is allocated directly to the dynamic“volumetric” floor plan without the need for the booking request to beallocated to a Gantt chart or other scheduling type chart or formatbefore allocation to the dynamic floor plan.

In one embodiment the “volumetric floor plan” is dynamic such that thevolumetric floor plan dynamically changes with time and the movement ofobjects including tables in accordance with the booking allocated.

In one embodiment the “volumetric floor plan” is used to forecast twodimensional floor plans a particular point in time and these forecastedfloor plans can be provided to a user together with instructions to theuser so that they can identify and find their allocated table withoutassistance such that they can “seat themselves” and eliminate the labourcosts incurred by a venue in undertaking this activity. In a furtherembodiment this dynamic floor plan can be used by a venue together withthe booking request option provided by the system to permit “walk-in”customers to request a booking through a kiosk, another venue device, abooking widget, app that a user can access through their own device andbe provided with the real time floor plan and directions to their tableto be able to “seat-themselves” as part of a “self-seating” process.

In one embodiment the forecasted “volumetric floor plan” is offered tovenue operators so that they can use it in the planning, staffing andoperational aspects of a service.

Dynamic Booking Allocation Examples

FIGS. 5a to 5e illustrate the steps taken by the iterative allocationprocess in determining an optimal arrangement of furniture within a subspace. FIG. 5a illustrates a to-scale arrangement of furniture 500within a venue prior to the allocation of any allocated booking requests502. FIG. 5b shows a first booking request made by Paul for twentypeople 504. The optimisation module generates an optimised spaceallocation set 506 which shows that the tables 71-710 of FIG. 5a havebeen joined together to form table 71 in FIG. 5b . Further, theoptimised space allocation set 506 also includes new tables 711-714,which have been added from storage and are automatically optimised intothe space remaining from combining tables 71-710.

Referring to FIG. 5c , a second booking request 508 is made by Jen forten people at the same time as the first booking. The allocation modulegenerates an optimised space allocation set 510 which shows that thetables 41-44 of FIG. 5b have been joined together to form table 41 inFIG. 5c . Further, the optimised space allocation set 510 also includesa new table, which has been taken from storage and placed in the spaceas part of table 41 to accommodate the table of ten.

Referring to FIG. 5d , a third booking request 512 is made by Peter foreight people at the same time as the first and second bookings. Theoptimisation module generates an optimised space allocation set 514which shows that the tables 61-64 of FIG. 5c have been joined togetherto form table 61 in FIG. 5 d.

Referring to FIG. 5e , a fourth booking request 516 is made by Sam forten people at the same time as the first, second and third bookings. Asall the bookings are for the same time period and as the allocationmodule unseats and reseats all previous booking requests in an iterativeprocess to ensure optimisation the entire allocation process wasundertaken on receipt of the booking request for Sam for 10 people 516.Further as the optimisation module, in one embodiment, allocates eachbooking in order of the size of the booking, Paul's and Jen's bookingswere allocated to the same space and tables as previously allocated.Next it was Sam's request that needed to be allocated being larger thanPeter's, and, as the area where table 61 was located in the previousiteration can accommodate a maximum of 10 people, optimising that spacerequires that Sam's booking is allocated to table 61. To do this afurther table is taken from storage to create a new table 61 in FIG. 5e. Peter's booking was then considered by the optimisation module togenerate an optimised space allocation set 518 which shows that thetables 711-714 of FIG. 5d have been arranged and joined together to formtable 711 in FIG. 5e and re-allocated the booking for Peter for 8 peopleto this allocation.

Further, the optimised space allocation set 518 also includes a newtable which has been added from storage to be accommodated in the spaceas table 715.

Referring to FIGS. 5f to 5s , the booking allocations are shown on aGantt chart 530.

Referring to FIG. 5f , the Gantt Chart 530 illustrates the passage oftime in 15-minute intervals across the top 532, (on the horizontalaxis), the table numbers 534 and the maximum number of chairs at eachtable (in brackets) 536 on the vertical axis. Further, the horizontallines between the table numbers illustrate the external tables within asection, being a row of tables that can be joined together to formdifferent combinations of larger tables to accommodate different bookingrequests 538. The booking algorithm also has the ability to add orremove tables from a section, if the addition or removal of tables willresult in a more optimised outcome. Horizontal lines surrounding asingle table represent a fixed table 540, as its capacity is fixedwithin the selected floor plan layout. Alternatively, two or more tableswithin the horizontal lines represent flexible seating or a section, asthe tables can be moved by the algorithm to form one or more largertables. The vertical axis therefore clearly shows that the floor plancomprises different fixed and flexible seating areas within an area ofthe venue. Also, shown on the table on the vertical axis, are theheadings “Atrium” 542 and “Front Room” 544, highlighting the twosubspaces being the Atrium 542 and the Front Room 544.

FIGS. 5f to 5s provide examples of how the venue and requestorconstraints are set and how the algorithm utilises the constraints inthe booking allocation process. In the example restaurant that forms thebasis of FIGS. 5f to 5s . the venue constraints are set so that abooking request will be firstly allocated within the Atrium subspace 476before it is allocated to the Front Room subspace 478 (as this is deemeda more efficient allocation in the context of the example restaurant).The floor plan shown comprises two spaces, the first space being the“Main Dining Room” 474, which comprises 3 subspaces which are the Atrium(larger dining subarea) 476, the Front Room (smaller dining area) 478and the Colonnade (outdoor area) 480. The second space 472 is a bar areacomprising only one table.

A review of the Gantt chart 530 of FIG. 5f , shows details of all priorbookings taken for the service period displayed, and a review of thetable allocations shows, to an observer, that there does not appear tobe any available space to accommodate a further booking for 10 people at8:00 pm for a two hour duration till 10 pm. FIG. 5g shows the ‘opposite’view or ‘inverse’ view of FIG. 5f , namely all available tables for theservice period are displayed rather than all booked tables. Again, avisual inspection of FIG. 5g does not indicate that there is anyavailability for the aforementioned booking request. In other words, avenue operator would conclude that the venue is unable to accept thebooking request and would reject such a booking request. Moreover, allknown booking systems would reject a booking request for 10 people at8:00 pm with a two hour duration with the same starting conditions.

Despite FIG. 5f showing no obvious availability for a booking requestfor 10 people at 8:00 pm for Yuko Nakagawa, when the booking request wasinputted into the embodiment, the booking was accepted without creatinga conflict, as can be seen in FIG. 5h . In this example, the algorithmseats the Yuko booking by undertaking the following steps:

-   -   1. Unseating all previous bookings;    -   2. Reallocating all bookings based on the largest metric (the        volume metric being the number of people multiplied by duration)        and most difficult metric (the largest booking taking up largest        area which contains the greatest number of possible        permutations); and    -   3. Clustering other bookings around the larger bookings by order        of volume metric and difficulty metric;

Referring to the specific example, for Yuko Nakagawa, the size of herbooking is 10 people multiplied by 2 hours (3 Courses A la Carte)resulting in a volume metric of 20 hours. Max Zambon, whose booking wasalso for 10 people multiplied by 1.5 hours (2 Courses A la Carte)results in a volume metric of 15 hours. As such, Yuko is allocated aheadof Max on table 610, FIG. 5 h.

After Yuko's allocation, the algorithm allocates Max on table 41 whichis available and can accommodate his booking without conflict as shownin FIG. 5 h.

In another example, returning to FIG. 5f before the booking request ofYuko on FIG. 5h . Yuko's request is now amended to create a bookingrequest for 10 people at 7:30 pm for three courses finishing at 9:30.From the Gantt chart in FIG. 5f there remains, no availability which isreadily apparent. However, utilising the algorithm, the booking requestof Yuko is successfully undertaken, as shown in FIG. 5j . Thereallocation process was undertaken as follows by the algorithm:

-   -   1. All previous bookings unseated;    -   2. Reallocating all bookings based on the largest metric (the        volume metric being the number of people multiplied by duration)        and most difficult metric (the largest booking taking up largest        area which contains the greatest number of possible        permutations) Subsequently clustering other bookings by order of        volume and difficulty around previously allocated bookings;    -   3. Continuing the allocation process and ultimately clustering        other bookings around the larger bookings, again by order of        volume metric and difficulty metric;    -   4. The size of the Yuko booking is 10 people multiplied by 2        hours (3 Courses A la Carte) resulting in a volume metric of 20        hours. Max's booking is also for 10 people multiplied by 2 hours        (3 Courses A la Carte) also resulting in a volume metric of 20        hours as per FIG. 5i . While the volume of both bookings is 20        hours, Yuko is allocated before Max on table 69 as it provides        better clustering and a more optimised allocation as illustrated        in FIG. 5 j;    -   5. Additionally, Yuko's booking is deemed to be more difficult        to accommodate and covering an area of more permutations as her        booking is closer to the period between 7 pm-8 pm defined within        the system as the ‘peak’ booking time period as per FIG. 5j ;        and    -   6. After Yuko's allocation, Max is allocated on table 41 which        is available and can accommodate his booking without conflict as        per FIG. 5 j.

In FIG. 5k . Yuko's booking, for the purposes of the example, is amendedto vary the start time from 8:00 pm to 7:30 pm. In the context of theexample, the venue constraint information includes a defined “peakperiod” 527 between 7 pm and 8 pm, such that the algorithm flags bookingrequests with a start time between the period between 7 pm to 8 pm asbeing the “most difficult” and are therefore placed in the “mostdifficult” matrix (multiple peak periods can be encoded into theembodiment). Due to the variation in Yuko's requestor constraintinformation, all allocated booking are unseated, placed in a pooltogether with Yuko's requested change and all bookings are reallocated.Yuko's booking request resides in the more difficult matrix so thebooking request is allocated first and all remaining bookings aresubsequently allocated. FIG. 5k illustrates that Yuko's booking has beenmoved to table 68 from table 69 on FIG. 5j . The reallocation wasundertaken as table 68 permitted better clustering and use of floorspace than table 69.

FIG. 5l illustrates a table 531 highlighting various bookingallocations. Firstly, a booking is shown at 5:30 pm for Julia Gao ontable 46, at 599, and a booking is shown for Eric Constantinidis for 6people at 9 pm on table 81, at 533. Eric is also noted as a “SVIP”,which means Eric should be given a guaranteed allocation to hisfavourite table. A review of the CRM system shows that Eric's favouritetable is table 46, as can be seen in FIG. 5m . which illustrates aninput box 537 for Eric's customer information including an edit tab 539and a table preferences tab 553. In the edit tab 539, the customerinformation includes a first name 541, a last name 543, an email 545, amobile number 547, a membership number 549 and a membership level 551.In the table preferences tab 553, there is included, for each restaurant555 and 561, a primary preference (557 and 563 respectively) and asecondary preference (559 and 565 respectively).

Returning to the example, Eric cannot be allocated to his favouritetable as it has a maximum seating number and table 46 is alreadyallocated to another booking request, namely Julia Gao. The allocationof Eric's booking on table 81 can also be seen on FIG. 5 n.

In reference to FIG. 5o , as an example of the manner in which theallocation module operates, if Eric's booking is reduced from 6 peopleto 4 people and the start time is varied from 9 pm to 6:15 pm to createa conflict with Julia's booking which was already allocated to table 46.The algorithm receives the change request and reallocates Eric to table46 despite the conflict with Julia as:

-   -   1. SVIP customers are allocated before non-SVIP customers. As        such, Eric is given priority and preference when the booking        algorithm identifies the SVIP ranking in the reallocation        process. The algorithm then searches the CRM system to determine        Eric's preferred table as being table 46 and allocates the        request accordingly.    -   2. Subsequently, the booking algorithm allocates Julia Gao's        booking and as table 46 is now taken, it allocates Julia to        table 82, (see FIG. 5n ) with all booking requests being        accommodated.

FIG. 4e illustrates one embodiment of a venue floor plan 401 whichcomprises two spaces 472 and 474. Space 472 has been defined as the“Bar” and comprises one fixed table while space 474 has been defined asthe “Main Ding Room” and comprises three subspaces; 476 defined as theatrium subspace, 478 defined as the front room subspace and, 480 as thecolonnade subspace. Within the atrium subspace 476 there are 4 sections482, 484, 486 and 494 which represent the flexible table areas whereobjects and tables can be rearranged. In the front room subspace thereare two sections 490 and 492 while in subspace 480 there are no sectionsmeaning all tables within that subspace are fixed. Further, in oneembodiment the venue constraint information includes informationprovided by the venue operator as to which spaces, subspaces andsections are open and information concerning which space or subspace toallocate and optimise bookings to first.

FIG. 4e illustrates one embodiment of a venue floor plan 401 whichcomprises three classes a luxury class 499 and 477; a premium class 479and 498 and a standard class 481, 496 and 483

In FIG. 5p there is illustrated a table 589 with three bookings of 12people at 5:30 pm. The first booking 591 is allocated in the atriumsubspace to table 61 as it is the first priority area and in the 60'ssection as this is the only table area that can accommodate a bookingfor 12 people (591), as shown in the table map 593 of FIGS. 5q . 5 r and5 s. Two additional tables are added to the 60's section. Moreover, by“joining” the tables together to make a table for twelve, additionalfloor space becomes available and the algorithm adds two further tablesfrom storage. The second booking 595 for 12 people is allocated to theatrium on table 67 as this is the next table area within the atrium thatcan receive a booking for a table of 12. Again a further two tables areadded to the restaurant floor plan 593 making a total of 4 tablesbrought in from storage as shown on FIG. 5r at 595. The third booking597 for 12 people cannot be accommodated within the atrium subspace soit is allocated to the next priority area being the front room (on table31). A further table is brought in from storage to complete the numberof tables required, as shown in table plan 593 of FIG. 5s at 597. As canbe seen from the example, the embodiment prioritises bookings by spaces,subspace, sections, classes etc., including as the step of addingadditional furniture as required for the optimisation of outcomes.

Referring again to FIG. 2c by way of example, the user interface 204 andthe input receiving module 206 may query the requestor. The querying ofthe requestor may include the proposal of at least one alternativealternate instance to the requestor by the user interface. Analternative instance proposed to the requestor may include but is notlimited to the use of the space at a different time or a differentduration time or a different number of courses, or a different day or ata completely different venue. The requestor may select at 206 onealternate instance which is received by the input receiving module 206.

The input receiving module 206 provides the alternate instance selectedby the requestor to the optimisation module 208 which processes anddetermines the optimised space allocation set 214 (including thealternative instance) in the same manner as it would process a normalrequest.

In an embodiment, the optimisation module 208 may also include anincentive module (not shown) which determines whether to provide furtherincentives to the user in order to incentivise the user to accept analternate instance as part of the optimisation module and alsodetermines which incentive to offer. The incentive may be in the form ofa discount to the remote user for the use of the space, or a discountfor a related purchase. The incentive may also include other offers ofgoods, services or discounts as determined by the operator or incentivesthat have been determined by the predictive module 220 as beinghistorically popular in incentivising the remote user to accept analternative instance.

Optimisation Flowchart

Referring to FIG. 6a , there is shown a flow-chart 600 that describesthe process of accommodating different types of spaces within a venue.In this embodiment, the venue is a restaurant and the objects aretables.

A new booking request is made by a requestor via the user interface 602.The user interfere may receive a private dining room request (“PDRrequest”) 604, that is a request to use a self-contained and privateroom within the restaurant. As such, the skilled addressee wouldunderstand that a private dining room may not form part of the normalrestaurant area and may be defined as a separate space, subspace orsection. If the remote user makes a PDR request, the user interface mayrequire further requestor constraint information 601 and may bespecifically configured to query for information from the requestor.Further requestor constraint information may include but is not limitedto, the particular room selection, planning the room layout, tools toamend the room layout, menus, seating positions, customer CRM details,whether the room has been tentatively booked or confirmed, whether adeposit has been paid or whether the room has been paid for in full. Thebooking is then allocated using the PDR allocation process 606.

Alternatively, the requestor may make a request for a bar area booking608 and the user interface may query the requestor for additionalinformation from the user relating to the particular booking type, offeradditional services and access CRM details 603. The booking is thenallocated using the Bar Area allocation process 610

Alternatively, the user interface may query the status of the requestor612 and 615, to determine whether they are a Very Important Person(“VIP”) or “super” VIP and may be specifically configured to undertakespecial actions 605 if the requestor is identified as a super VIP oraction 607 if a VIP. The booking is then allocated using the Super VIPor VIP allocation process 614 or 617 respectively.

Alternatively, the requestor may make a request for the main dining areabooking in the first booking segment, or first dinner sitting 616 (if aservice has been divided into booking segments or seating periods), andthe interface may query the requestor for any additional informationrelating to the particular booking type and time 609. The booking isthen allocated using the First Booking segment allocation process 618.

Alternatively, the requestor may make a request for the main dining areabooking in the second booking segment, or second dinner sitting 620, andthe interface may be specifically configured to query the requestor foradditional information relating to the particular booking type and time613. At any point in receiving the additional information, a request canbe allocated, or an alternative offered, in a dynamic process ofallocation. The booking is then allocated using the Second bookingsegment allocation process 622.

Alternatively, the booking process terminates 611.

Referring now to FIG. 6b , by way of example, the user interface mayreceive a private dining room request (“PDR request”) 604. That is, arequest to use a self-contained and private room within the restaurant.In order to allocate the request, the user interface displays variousinformation types 6003 on the private rooms screen (displayed to thebooking requestor) 6001, including the number of rooms 619, theconditions of the private rooms 621 the requirement for deposit and orfinal payment 623, and terms and conditions regarding menu and spend625. In allocating the request, the optimisation module queries whetherthe PDR request is made in respect of a specific room 624, 627, 629,etc. If no specific room is booked, the request is rejected 631 andprocess ends 633. If a specific room has been chosen, for example therequest is made for private dining room number 1 (“PDR 1”), the processcontinues. The optimisation module determines whether the rooms arealready booked 626, where if it is available, then PDR request isprovided further information to complete the booking request, includingproviding a planning and configuration tool 637, advising terms andconditions 639, allowing the customer to accept the conditions and pay641, process payment 643, accept the booking 645 and end the process633. However, if the PDR is already booked but not confirmed 628, thenthe request can be placed on a wait list 651, at which time the customeraccepts conditions and is advised of conditions with regard to being onthe waitlist 653 and 655, and the process ends 633. Alternatively, thesystem offers an alternative room 647, which the customer may accept orreject, and, at the requestor choice if they do not accept analternative the request is cancelled 633.

Referring to FIG. 6c , the user interface may receive a request to use abar area booking 608. In order to allocate the request, the userinterface displays various information types 659 on the bar area screen(displayed to the booking requestor) 657, including the conditions ofthe bar area 661, the requirement for deposit and or final payment 663,and terms and conditions regarding menu and spend 665. In allocating therequest the optimisation module queries whether the request is made inrespect of a bar area 1 630, 667, 669, etc. If no specific area isbooked, the request is rejected 631 and process ends 633. If a specificarea has been chosen, such as bar area 1, the optimisation module 632determines whether the bar is already booked, where if it is available,then the request is provided further information to complete the bookingincluding advising terms and conditions 639, allowing the customer toaccept the conditions and pay 641, process payment 643, accept thebooking 645 and end the process 633.and the bar area is booked inaccordance with the request 645 and the process ends. However, if thebar area is already booked but not confirmed 634, then the request maybe placed on a wait list 651, at which time the customer acceptsconditions and is advised of conditions with regard to being on thewaitlist 653 and 655, and the process ends 633. Alternatively, thesystem offers an alternative 647, which the customer may accept orreject at which time the process ends 633.

Alternatively, referring to FIG. 6e , the user interface may query thestatus of the requestor, to determine whether they are a Very ImportantPerson (“VIP”) 615 or super VIP 612. The optimisation module willattempt to determine if they have a preferred table 638 and if the tableis available 640. If the table is available then allocate the table 642in accordance with the request. However, if the VIP the does not have apreferred table and there is an available table where the number ofseats is equal to or less than the maximum number of patrons and greaterthan the minimum number of patrons 644, then the table is allocated.

Otherwise, if there are one or more VIP requestors wishing to use aparticular table 646, then the optimisation module allocates the nextbest table to each of the VIP requestors in the order of their rankingwithin the VIP status (as shown in FIG. 6e ).

Alternatively, referring to FIG. 6d , the requestor may make a requestfor the main dining area booking in the first booking segment, or firstdinner sitting 616. When allocating the pool of requests, the allocationmodule first attempts to allocate the first booking by allocating thelargest booking metric and most difficult booking metric at 671, andsubsequently allocate to a non-allocated table where the size of thebooking request equals the maximum number of seats for a fixed table648.

If the above request can be accommodated then the table is allocated,otherwise, the allocation module attempts to allocate the largestbooking to a non-allocated table that cannot be joined (“fixed tables”)where the patrons equal the minimum number of seats 650.

Referring to FIG. 6f , if the above request can be accommodated then thetable is allocated, otherwise, the optimisation module attempts toallocate the largest booking to the smallest section (“flexible table”location) 652.

If the above request can be accommodated, then the table is allocated,otherwise, the optimisation module attempts to allocate the largestbooking to the second smallest section 654.

If the above request can be accommodated, then the table is allocated,otherwise, the optimisation module attempts to allocate the largestbooking to the third smallest section 656.

Referring to FIG. 6f , if the above request can be accommodated, thenthe table is allocated, otherwise, the optimisation module attempts toallocate the largest booking to the fourth smallest section or anysubsequent smallest section until all sections are exhausted 658.

Referring to FIG. 6g , if the largest booking cannot be accommodatedwithin a single section, the allocation module attempts to allocate thelargest booking within the smallest combination of adjacent sections andfixed tables of a minimum size 670 and cluster smaller booking aroundlarger bookings 680.

Referring to FIG. 6h , if the last booking being allocated from the poolof bookings cannot be allocated, then the embodiment allocates the lastbooking to the smallest possible joint floor space and displaces thepreviously allocated bookings to those tables and attempts to reallocatethe displaced bookings 684.

User Interface Screens

One embodiment of the computer system includes a user interfaceproviding module arranged to provide a user interface to at least oneremote user via a communications network. The computer system may alsoinclude a user interface directed to one or more users associated withthe venue.

Referring to FIGS. 7a to 7n , a non-limiting example of one of thescreens displayed on a user interface 700 directed to one or more usersassociated with the venue is shown. The user interface 700 may includeone or more of the following user interface modules, which may bearranged in any number of ways to best suit the one or more operators.The screen 700 is a non-limiting example provided to illustrate theworkings of the interface. The interface provides a “dashboard” or“cockpit”, utilising a screen layout for use during a service period.The venue operator does not need to leave the screen to access or seeall relevant information required during a service period includingbooking messages, home delivery orders, run sheets and emails.

For the following detailed description referring to FIGS. 7a to 7n ,like numerals across different Figures refer to like features and/orintegers.

The user interface 700 may include a restaurant summary and revenuemodule 702, which displays a number of general details of or related tothe venue. Such details include, but are not limited to, the name of thevenue, the date and the time at the location of the venue, theanticipated weather during the service times of the restaurant(indicated by B for breakfast, L for lunch and D for dinner, S forsupper, or any alternative service the restaurant manager or operatorwishes to create), the number of bookings, number of people, the numberof people in the venue without bookings, the number of cancelledbookings or bookings that do not eventuate, the number of people who donot attend, total revenue and average revenue per person for a giventime and date. The restaurant and revenue summary module 702 may alsoinclude the anticipated revenue measures (such as total revenue orrevenue per available seat), details of any currently running promotionsor notes regarding nearby or related events. There may also be provideda revenue and capacity module 731.

The user interface 700 where the venue is part of a multi-venue customergroup to select the preferred restaurant from the drop down at 774whereby the time shown at 789 will automatically change to show thecorrect time for that restaurant at its physical location such thatscreen 700 represents a multi-venue, multi-time diary and screen andwill eliminate booking errors when bookings are taken at a time zone orlocation that is different to that of the physical location of therestaurant.

The user interface 700 may include a space allocation user interfacemodule 706. The space allocation user interface 706 describes at leastone optimised space allocation instruction set 734 to the operator insuch a way as the operator can follow the instruction set to optimisethe set out and functionality of the venue. The optimised spaceallocation instruction set 734 may be provided in a graphical manner (asshown in FIG. 7b ) which shows a representation of the floor plan of therestaurant and the “to-scale” arrangement of furniture within the spaceand subspaces of the venue. Alternatively, the skilled addressee wouldreadily understand that the optimised space allocation instruction set734 may be alternatively codified in a set of written instructions (notshown) or in an interactive graphical “map” that allows the user to“drag and drop” the furniture in the space or subspace, or “click on”the pieces of furniture to bring up further information relating to theallocation or booking of that furniture of the venue to provide theoperator with an understanding of how to best arrange the objects in aspace to optimise the operation of the venue. To assist the operator infollowing the optimised space allocation instruction set 734, thecomputer system may identify the individual tables by assigning a uniquenumber or other identifying means.

The space allocation user interface module 706 may further include oneor more sub space allocation interface modules 736 which may displayinformation relating to an optimised space allocation instruction setfor objects in a sub-space 736. The space allocation user interfacemodule 706 may further include one or more PDR allocation interfacemodules 738 which may display information relating to an optimised spaceallocation instruction set for a PDR 738.

The space allocation user interface module 706 may further include oneor more object storage modules (not shown), which display informationrelevant to objects not currently on the floor of the venue and arestored in a storage space.

As appreciated by a person skilled in the art, any of the modules of theuser interface 700 may be displayed as a number of graphical symbolsillustrating the attributes of the furniture (such as the maximum numberof seats, the shape of the table and accompanying chairs, etc.), or as alist or interactive graphical “map” that allows the user to “drag anddrop” the furniture in or out of the storage space or “click on” thepieces of furniture to bring up further information relating to thefurniture of the venue to provide the user associated with the venue theunderstanding of how to best arrange the objects in a space to optimisethe running of the venue.

The user interface 700 may also include a diary module 708 which liststhe booking details of one or more user requests 704. The diary module708 may include a number of subcategories such as waiting “walk-in”users or customers, being users with no previous booking, on a“waitlist”, unallocated bookings which are bookings that have not yetbeen accommodated by the optimisation module, or other seating timesthat compartmentalise the total service times into discrete mealperiods. A request that falls under any of these subcategories may beincluded in the diary module 708 in a manner that displays the bookingtime, the status (being waitlisted “W”, unallocated “U”, or confirmed“C” or any other category determined by the operator), the name of theuser making the request, the number of people in the booking, the tableidentification number (if applicable), the number of times the user hasvisited previously, the menu style (such as al a carte menu, specialisedmenu, or a theatre menu), the booking reference and any specialrequests.

The user interface 700 may also include a graphical diary module 710,which displays the booking details of the user requests across theservice time period. The graphical diary module may be represented in anumber of different ways. One example of the graphical diary module isshown at 710, which displays a Gantt-Chart style diary which illustratesdifferent table bookings for each user across the service time period. Avertical line indicates the current time such that the operator is ableto view current and future booking information at a glance and is timesensitive and moves within its “window”.

The user interface 700 may also include an alternative form of agraphical diary module 712 in FIG. 7e , which is time sensitive andmoves within its “window” and illustrates the sections of time which donot have an accommodated booking for each of the tables in the venue.This allows the operator to view sections of the service time period toeasily determine when the next table is available. This is particularlyuseful in accommodating walk-in users who have not made a bookingamongst user requests allocated by the computer system.

The user interface 700 may also include a customer walk-ins list 714,which displays a list of walk-in users. The module may display detailsof the walk-in, such as their name and contact details, the number ofpeople in the booking, the time the walk-in arrived, the next availabletable that can accommodate the walk-in and the time that the table wouldbe available. To assist the operator in managing the customer standbylist, the lists may be ordered by the oldest walk-in arrival time and/ormay be coloured coded to identify the relative urgency that the walk-inshould be accommodated. For example, the first walk-in is indicated byred colouring 716, and later walk-in entries are shown in greencolouring 718 or orange colouring 720. An embodiment of the inventionincludes the computer system directly contacting the walk-in when thetable that have been allocated by the computer system is available. Thewalk-in may be contacted via Short Message Service (SMS) or may promptthe operator to contact the walk-in.

The user interface 700 may also include an urgent message for thisservice module 722, which may be remote user enquiries that may bereceived by the user interface in the form of an email 724, SMS 726, orvoice-to-text translations from a phone message bank service received bythe computer system from one or more remote users.

The user interface 700 may also include an email module 728, which maybe configured to display emails addressed to the operator.

The user interface 700 may also include a home delivery orders takenduring service module 730, which may be configured to display anybookings that are taken by the computer system during the service periodat the venue. This is particularly useful in understanding wait timesfor food with respect to seated customers and potential walk-incustomers. The combining of customer dine-in orders with home deliveryorders also permits the system to notify customers of wait times,prioritise orders and co-ordinate the activities of kitchen staff andwait staff.

Any of the above modules described may include an expansion tab icon orbutton 732, which, if clicked on by the operator, can expand the size orfunctionality of the module as a “pop up window”, where the pop upwindow may be a new screen on the user interface that is opened on topof any previous windows.

An example of a pop up window relating to the email module 728 of theuser interface 700, is shown at FIG. 7j . When the operator clicks onthe expansion icon or button 732 for the email module 728, a new emailwindow 740 “pops up” over the user interface dashboard 700. The newemail window 740 may have enhanced or additional functionality than isprovided by the email module 728.

A further example of a pop up window relates to the restaurant summaryand revenue module 702 of the user interface 700, is shown at FIG. 7k .When the operator clicks on the button “Rev & Util” for the restaurantsummary and revenue module 702, a “new” restaurant summary and revenuewindow 742 “pops up” over the user interface dashboard 700. The newrestaurant summary and revenue window 742 may have enhanced oradditional functionality than is provided by the restaurant summary andrevenue module 702.

The restaurant summary and revenue module 702 provides an advantageousinsight into the operation of the venue. There are numerous metricswhich are calculated within the embodiments of the system for yieldmanagement, forecasting and for the autonomous operations the system,examples of which are included within Annexure 2, with relevant priorart included as Annexure 1. However, in the embodiment, displayed on theuser interface or dashboard of the system are revenue yield 701, seatutilisation 703 and efficiency 715. Each may be represented as:

${{Revenue}\mspace{14mu} {yield}\mspace{14mu} \%} = \frac{{actual}\mspace{14mu} {revenue}}{{retail}\mspace{14mu} {price}\mspace{14mu} {of}\mspace{14mu} {items}\mspace{14mu} {sold}\mspace{14mu} {and}\mspace{14mu} {complimentary}\mspace{14mu} {items}\mspace{14mu} {provided}}$${{Seat}\mspace{14mu} {utilisation}\mspace{14mu} \%} = \frac{{revenue}\mspace{20mu} {seat}\mspace{14mu} {hours}}{{available}\mspace{14mu} {seat}\mspace{14mu} {hours}}$Efficiency  % = revenue  yield  % × seat  utilisation  %

The revenue yield is the actual revenue generated divided by the retailprice revenue (excluding discounts, promotional benefits or gifts) 701at FIG. 7k . The seat utilisation is the revenue generated by each seatper hour divided by the number of hours the seat is in use 703. TheEfficiency of the restaurant is calculated as the revenue yieldmultiplied by the seat utilisation. The calculation of efficiency asshown at 715 provides the user associated with the venue with a truemeasure of the efficiency of the operation of the restaurant acrosstime.

A further embodiment includes a pop up window relating to a specificuser request or booking 704 shown in the diary module 708, as shown atFIG. 7l . When the operator clicks on the user request or booking record704, a new reservation window 744 “pops up” over the user interfacedashboard 700. The new reservation window 744 may have enhanced oradditional functionality compared to the diary module 708 and provides adetailed look at the details of the user request or booking.

For example, as shown at FIG. 7l , the reservation 704 is a request touse a private dining room (PDR) which includes a seating allocation planfor the table with corresponding seating or guest allocation 746, the“run sheet”, which shows the timing of the venue experience 748, theremote user or a patron's contact details 750, the function details 752including table and guest position numbers, the menus selected by theremote user, any additional items requested by the remote user, thedetails of what is required for the set up for the booking, the termsand conditions agreed to by the remote user, and any notes made by theoperator. The new reservation window 744 also includes the paymentstatus of the bookings 754 and a “log” history 756 of actions taken byany operators.

A further embodiment is provided where the use of the entire space ofthe venue is requested. A further embodiment of a pop up window relatingto a specific remote user request or booking, is shown at FIG. 7m . Afunction window 745 is shown which includes an optimised spaceallocation instruction set seating allocation 747, the run sheet showingthe timing of the venue experience 748, the remote user's or a patron'scontact details 750, the function details 752 including table and guestposition numbers, the menus selected by the remote user, any additionalitems requested by the remote user, the details of what is required forthe set up for the booking, the terms and conditions agreed to by theremote user, and any notes made by the operator. The reservation windows744 and 745 also include the payment status of the bookings 754 and a“log” history 756 of actions taken by any operators. There is alsoprovided a “function confirmed” button at 793, which allows the operatorto view all functions that have been confirmed.

A further embodiment of a pop up window relating to a specificindividual user request or individual booking 704 shown in the diarymodule 708, is shown at FIG. 7n . When the operator clicks on the userrequest or booking record 704, a new reservation window 758 “pops up”over the user interface dashboard 700. The new reservation window 758may have enhanced or additional functionality compared to the diarymodule 708 and provides a detailed look at the details of the individualuser request or booking. For example, as shown at FIG. 7n , thereservation 704 is a request for a table of 6 people. The newreservation window 758 includes a seating allocation plan for the tablewith corresponding seating or guest allocation 760, the a guest list ofpatrons 762, the menus selected by each patron 764, any “restaurantbutler” request 766, where restaurant butler request include theprovision of any additional goods or services that a “butler” mayprovide to supplement the patron's experience, the customer relationshipmanagement (CRM) module including the remote user or patrons favouriteexperiences or foods, staff's (users associated with the venue) commentsor feedback, dietary requirements and visit history. The new reservationwindow 758 also includes the payment status of the bookings 770.

In a further embodiment, the dashboard and diary user interface 700 inFIG. 7a , contain details of the exact time 789 of the restaurant usingthe time zone of the restaurant's location 774.

In a further embodiment, the dashboard and diary user interface 700 inFIG. 7a , contain a booking form for the booking of functions and events776 which is linked in the data base with a corresponding functionbooking app and widget.

In a further embodiment, the dashboard and the diary user interface 700in FIG. 7a , contain a booking form for the booking of a table 780 andalso a booking form for the booking of private dining rooms or privatespaces 778 which is linked to the data base with a corresponding privatedining room app and widget. An unconfirmed function booking list mayalso be provided at 790.

In a further embodiment, the dashboard and the diary user interface 700in FIG. 7a , includes a “pop up” that can immediately communicate to arestaurant user all the constraints that have been applied to thatservice 788.

In a further embodiment, the dashboard and the diary user interface 700in FIG. 7a includes a function set up menu for all the constraints anddetails to be included and added to the data base 782.

In a further embodiment, the dashboard and the diary user interface 700in FIG. 7a , includes a restaurant set up menu for all the constraintsand details to be included and added to the data base 772.

In a further embodiment, the dashboard and the diary user interface 700in FIG. 7a , includes a delivery set up menu for all the constraints anddetails to be applied to delivery orders which is linked to the database with a corresponding app and widget 786.

In a further embodiment, the dashboard and the diary user interface 700in FIG. 7a , includes a gift shop set up menu for all the constraints tobe included for the sale of gift cards, gift packages and gift productswhich is linked to the data base and with a corresponding app and widget784.

In further embodiments the dashboard and diary user interface 700 inFIG. 7a , includes integrated modules for cabaret show bookings, CRMinformation for seating allocation constraints and customer service,reporting, accounts, forecasting and predictive analysis and point ofsale transactions and integration.

The computer system as claimed may also include the feature of a“restaurant butler” module which facilitates the provision of anyadditional goods or services that a “butler” may provide to supplementthe patron's experience. For example, the user request may include arequest for a dozen red roses to be included with a booking. Therestaurant butler accesses a database containing supplier informationrelevant to the request, such as, the details of a florist.

An embodiment is provided where the restaurant butler automaticallyprovides a prompt to the operator to contact the supplier and order theflowers, or the restaurant butler is configured to automatically orderthe roses via an email ordering system or other means. The databasewould also contain information relating to the estimated delivery timesfor the roses and other limitations (such as availability etc.), suchthat if a service or good was not available, the restaurant butler maysuggest an alternative.

As would be readily understood by the person skilled in the art, therestaurant butler is not limited to flowers and may also include theprovision of chocolates, musicians, magicians and other forms ofentertainment. The restaurant butler may also be configured tocommunicate with external computer systems over a network, such as theInternet, for ordering or procuring the relevant goods or serviceswithin established supply chains or automated systems.

An embodiment of the computer system includes the functionality toenable both the remote user and the operator to make a booking. Thisfunctionality provides particular use when servicing walk-ins, such thatthe operator may request a booking on behalf of the walk-in.

User Booking Interface Screen

Referring to FIG. 8, a non-limiting example of one of the screensdisplayed and the information contained on a user interface 800 directedto a remote user or an operator. The user interface screen 800 displaysa non-limiting example of the “Details” tab within the “make a booking”screen provided to a remote user and/or an operator. As would be wellwithin the purview of a person skilled in the art, the data fieldsdisplayed or queried by the “make a booking” screen may vary dependingon whether the user is a remote user or an operator. For the followingdetailed description referring to FIGS. 8a to 8j , like numerals acrossdifferent Figures refer to like features and/or integers.

The user interface 800 may include one or more of the features of abooking time summary 802, which details the number of allocated remoteusers at each predetermined service period or meal periods and the totalnumber of patrons and other metrics associated with achieving a specificturnover or number of patrons. Other features may include informationthat may be shown or queried from the remote user or operator, such asthe patron's personal and contact details 804 (where the patron may bethe walk in or remote user), the booking reference details 806, thebooking request particulars 808, the allocated booking details 810,marketing details 812, payment details 814, and booking history for theparticular requestor 816.

An embodiment of the computer system shown in FIG. 8c includes a userinterface module 808 which allows a remote user to pre-select a numberof the particulars of their request to use a space. The user preselectinterface module 808 may include the number of people 820, the beginningtime of the booking 822, the menu selection 824, the desired number ofcourses in the menu 826, the departure time 828 and the allocated time830. Based on the information entered by the remote user into thepreselect interface module 808, the user interface will automaticallyprovide a departure time which accounts for the number of people in thebooking and the number of courses selected. That is, the departure timewill vary depending on the selection of request particulars by theremote user. Further, the preselect interface module 808 also includesan option that allows the remote user to change their departure time832. The preselect interface module 808 automatically associates anadditional charge 833 to the user associated with the later departuretime in accordance with the opportunity cost of the space in the venuenot being used by other patrons. That is, the computer system seeks tooptimise the utilisation in respect of the time that the space isavailable.

The preselect interface module 808 may also include the option for theremote user to request an area or sub space of the venue 834, and aparticular table within the sub space 836. As before, the computersystem automatically varies the prices of the patron's experience at thevenue dependant on the ranking of the requested seat or sub-space, theitems selected in the menus, the number of courses selected, thefurniture comfort level, and/or service standard in accordance with theranking of that sub-space or table such that the remote user may chooseto upgrade certain elements of their experience.

For example, a venue is a restaurant with an a la carte menu is shown inFIGS. 8d and 8e . A remote user has previously selected a two coursemenu at the preselect interface module 808 (shown in FIG. 8c ) with anentrée course 838 and a main course 840 with accompanying side dishes842. The remote user makes a booking for four patrons 844, where each ofthe patron's meal choices 844 for each course is pre-selected. Once themeals have been selected, the remote user can then proceed to pay forthe meal by “adding to cart” by using button 846 and proceeding to payin a payment screen (not shown).

An embodiment of the computer system shown in FIG. 8c illustrates thecomputer system including a Marketing CRM input field where the remoteuser may enter the details of how the remote user became aware of thevenue. The Marketing CRM field may include any questions that relate tomarketing or managing customer (patron) relationships. Furthermore, thecomputer system may also allow remote users to pay remotely using asecure payment gateway over a network such as the Internet.https://en.wikipedia.org/wiki/Payment gateway). Alternatively, thecomputer system 200 may be integrated with a Point of Sale (POS) system,which allows the user to pay after the conclusion of the meal.

Alternatively, if the remote user previously selected a three coursemenu at the preselect interface module 808 (shown in FIG. 8c ), thecomputer system may provide an alternative menu. The alternate menu maybe varied such that some of the meal items of the entrée course 838 anda main course 840 may be greyed out or removed entirely and anadditional course, such as dessert may be added (not shown).

In one embodiment of the interface shown in FIG. 8g there is shown aninterface screen 800 which allows a requestor to part pay a pre-paymentrequirement over a number of installments at the customers choosing atany time before the final payment is required to be paid for the bookingto be secured and confirmed, including payment details 814 and a bookinghistory button 816.

Payments and Pre-Payments

Referring to FIG. 8h , in one embodiment of the computer system isdetailed an example of pre-payment constraints 212 that can be used todetermine whether a prepayment is required to secure a booking.

Referring to FIGS. 8i and 8j in one embodiment of the computer system isdetailed an example of the pre-payments decision tree to determine if abooking request is required to make a pre-payment for the booking to beconfirmed.

Referring in detail to FIG. 8i , the embodiment determines whether thepre-payment constraint is on at step 840. If not, the process ends atstep 842. If yes, then a series of cascading criteria are determinedutilising the constraint information, including whether pre-payment isrequired for the date 844, the day of the week 846, the service 848, thetime selected 850, the space, sub-space, section or class 852, thenumber of guests 854, the specific table 856, the extended bookingduration 858, additional services 860 or the menu selected 862.

Referring to FIG. 8j , which continues from flow arrow 1 of FIG. 8i , ifthe menu selected at step 864 is a fixed price menu 866, then theprocess determines if a deposit is payable 880, and if not, the processdetermines if a full amount is payable at 878, and if not, then theprocess determines if a booking fee is payable at 870, if not then atstep 872 the booking is confirmed. If a deposit is payable at any one ofsteps 880, 878 or 870, then the amount and date due is communicated atstep 882, the terms and conditions are communicated at step 884, and therequestor is directed to a customer payment module at step 886, afterwhich the booking is confirmed at step 872.

Returning to step 866, if he menu is not a fixed price menu, the processdetermines whether a choice menu deposit is payable at step 868, and ifnot, the process determines whether a booking fee is payable at step 870and if not, the booking is confirmed at step 872. If a deposit ispayable at steps 868 and 870, then the amount and date due iscommunicated at step 882, the terms and conditions are communicated atstep 884, and the requestor is directed to a customer payment module atstep 886, after which the booking is confirmed at step 872.

System Constraint Examples

A further alternative is provided where the embodiment automaticallyvaries the menu selection depending on the number of guests (pax).Referring to FIG. 9a , which shows a flow diagram 900 illustrating theautomatic decision making of the user interface in deciding which menuis provided to a requestor making a booking, depending on the number ofguests. When receiving a new request or booking 902, the number ofguests (pax) and time are assessed at time 901, to assess the requestfor whether it is a request for a private dining room (PDR) 904. If itis not a request for a private room, and there are less than eleven pax906, then the user interface provides the requestor with the full a lacarte menu 908. If the number of pax is between 11-16 (910), then theuser interface provides the requestor with a limited a la carte menu912. If the number of pax is between 17-30 (914), then the userinterface provides the requestor with an alternate drop menu 916. If thenumber of pax is over 30, exclusive function options are offered at 918.An example of a full a la carte menu is shown in FIG. 8 d.

Alternatively, if the number of patrons is between eleven and sixteen910, then the user interface provides the remote user with a limited ala carte menu 912. An example of an interface for a limited a la cartemenu 903 is shown in FIG. 9b , wherein a smaller range of availabledishes is provided to the remote user to select from.

Alternatively, if the number of patrons is between seventeen and thirty914, then the user interface provides the remote user with analternative drop menu 916. An “alternate drop menu” is a where the venueoffers a limited selection and the remote user chooses two dishes percourse which are served in an alternating manner for each guest.

Alternatively, if the number of patrons exceeds thirty patrons, the userinterface provides a list of exclusive function options and/or a list ofalternate venues that would be able to accommodate the booking 918. Aswould be readily understood by the skilled addressee, the limitation ofthe number of patrons per menu type is determined based on the capacityof the venue and the exemplary values listed were provided to assist inunderstanding the claimed invention. As such, it would be understoodthat a user interface may provide the remote user with any number ofmenus depending on any number of patrons in the booking.

In determining which menu to provide to the remote user, the userinterface, may access relevant constraint information or otherinformation, stored in one or more databases. Such information is shownin FIG. 9c , and the rules guiding the menu decision process 920includes but is not limited to the start and end of service times, thebooking intervals, the latest time a booking would be accepted, and themaximum number of patrons, tables, walk-ins, and number of people permenu type.

Further, the user interface may also access manually estimated(estimated and entered by the operator) or predicted (by the predictivemodule) times required per course for a number of patrons. For example,referring to FIGS. 9d to 9f , the user interface which includes theinput interface 905 of the various menus and number of courses involvedFIG. 9d , and then may rely on the rules 922 FIG. 9e which include thetimes for a first menu style (a la carte) for one course 924, twocourses 926 and three courses 928.

Alternatively, the user interface may rely on the rules 922 whichinclude the times for a second menu style (limited a la carte) for twocourses 932 and three courses 934.lternatively, the user interface mayrely on the rules 922 which include the times for a third menu style forone course 936, two courses 938.

In one embodiment, the user interface relies on the duration times setby courses and/or by requestor status as shown in FIG. 9f , where inputscreens for the time allocated to one, two and three course menus aredisplayed at 924, 926 and 928 respectively.

In one embodiment, the user interface groups all booking requests inaccordance with the seating periods determined for a service as createdand shown in FIG. 9g , including the setting of a table reset time at930.

The automation of the menu selection allows for larger bookings to beappropriately and automatically allocated without disrupting the normalservice of the venue by reducing the time and effort required to caterto large parties of patrons. As such, the embodiment addresses one ofthe problems identified in the prior art by providing a completerestaurant management system that transparently and autonomously managesthe relationship with the client from the beginning of the booking topayment and end of service.

In one embodiment, the computer system allows the venue operator todefine customised and non-standard financial and reporting calendar inaccordance with the constraints in FIG. 9h generally shown at 932. Theoutcome of the constraints set in FIG. 9h are shown in FIG. 9i at 934.

Referring now to FIG. 10a , there is shown a flowchart illustrating aprocess flow for a widget arranged to operate with an embodiment of theinvention. At step 1000, a venue is selected, and subsequently at step1002 a space and/or sup-space is selected. At step 1004, a date isselected. At step 1006, a service is selected and the number of guestsis selected at step 1008. At step 1010, an option to include children inthe booking may be selected, and if so, the process proceeds to step1012, where the number of children is input, and step 1014 where thenumber of high chairs required is inputted. Consequently, the methodmoves to step 1016, where the type of occasion is selected, and theavailability of type options is displayed at step 1018. The availabilityof type options displayed in accordance with the embodiment is one offour options.

Firstly, availability by menu and class is shown at step 1020 and isdescribed in more detail in FIG. 10 b.

Secondly, availability by time by class is shown at step 1026 and isdescribed in more detail with reference to FIG. 10 b.

Thirdly, availability by promotion by class is shown at step 1022 and isdescribed in more detail with reference to FIG. 10 b.

Fourthly, availability by specific table by class is shown at step 1024and is described in more detail with reference to FIG. 10 c.

Turning to FIG. 10b , there is shown a continuation of a flowchartillustrating a process flow for a widget arranged to operate with anembodiment of the invention. Following from step 1020 of FIG. 10a , allavailable menus are filtered by previously selected constraints areloaded at 1028, the requestor selects a menu at step 1030 and the menuis displayed at 1032. Dependent on the menus selected, all availabletime intervals are filtered at step 1034, utilising all previouslyelected constraints. The requestor selects a time interval at 1042, anda booking duration is calculated for the selected constraints at 1038.The requestor must then decide whether to select the booking durationextension option at 1070. If not, the booking request containing allpreviously elected and defined constraints is sent to the allocationmodule at step 1062 and the optimisation algorithm processes the bookingrequest at 1064.

Alternatively, following from step 1026 of FIG. 10a , all available timeintervals (time periods for a booking) are filtered by previouslyselected constraints are loaded at 1034 and the requestor selects a timeinterval at step 1042. Dependent on the time interval selected, allavailable menus are filtered at step 1028, utilising all previouslyelected constraints. The requestor selects a menu at 1030, and theselected menu is displayed at 1032. A booking duration is calculated forthe selected constraints at 1038. The requestor must then decide whetherto select the booking duration extension option at 1070. If not, thebooking request containing all previously elected and definedconstraints is sent to the allocation module at step 1062 and theoptimisation algorithm processes the booking request at 1064.

Alternatively, following from step 1022 in FIG. 10a , all availablepromotions are filtered according to previously selected constraints andare displayed to the requestor at step 1044. The requestor may select astandard promotion 1048 or a backfill promotion 1046, depending on theavailability of either option. Irrespective of which promotion ischosen, an associated menu is displayed at step 1032 and the bookingrequest containing all previously elected and defined constraints issent to the allocation module at step 1062 and the optimisationalgorithm processes the booking request at 1064.

Referring to FIG. 10c , there is shown a continuation of the flowchartof FIG. 10a illustrating a process flow for a widget arranged to operatewith an embodiment of the invention. Following from step 1024 in FIG.10a , a floor plan illustrating all available tables, filtered by thepreviously selected constraints is loaded at step 1070. The requestorselects a table at step 1072, a payment amount is displayed at step 1074and secondary availability options are also displayed at step 1076. Therequestor may select a specific table and firstly select availabilitybased on menu 1078 or by time at step 1092.

If the requestor chooses step 1078, then all available menus arefiltered at step 1028, utilising all previously elected constraints. Therequestor selects a menu at 1030, and the selected menu is displayed at1032. Available time intervals are loaded 1034 and requestor selects atime interval 1042. A booking duration is calculated for the selectedconstraints at 1038.

If the requestor chooses step 1092, then all available time intervalsare filtered at step 1034, utilising all previously elected constraints.The requestor selects a time interval at 1042, all available menus arefiltered at step 1028, utilising all previously elected constraints. Therequestor selects a menu at 1030, and the selected menu is displayed at1032. A booking duration is calculated for the selected constraints at1038.

Referring to FIG. 10d , there is shown a continuation of the flowchartof FIG. 10b illustrating a process flow for a widget arranged to operatewith an embodiment of the invention. The requestor may hold the bookingrequest temporarily at step 1019 or the booking request may not beallocated at step 1007.

If the booking request is held temporarily, the requestor (customer)details and/or additional information are captured (either by therequestor entering information or autonomously from a customer database)at step 1029, the booking request is allocated at step 1033 and receiptof the booking is sent to the customer at step 1035 after which theprocess ends at step 1025.

Alternatively, following on from the booking not being allocated at step1007, a popup will appear, displaying alternative booking options to therequestor at step 1009. The alternatives may be an alternative timeinterval at step 1015, a shortened booking duration at 1017, the abilityto join a waitlist at 1011 or a cancellation of the booking request atstep 1013. If the alternative time offered at step 1015 is accepted, theedited booking request is sent to the allocation module at step 1021 andat step 1064 the optimisation algorithm processes the booking request.Thereafter, the requestor may hold the booking request temporarily atstep 1019. The requestor (customer) details and/or additionalinformation are subsequently captured (either by the requestor enteringinformation or autonomously from a customer database) at step 1029, thebooking request is allocated at step 1033 and receipt of the booking issent to the customer at step 1035 after which the process ends at step1025.

If the shortened booking duration at step 1017 is chosen, incentives maybe offered at step 1023 in order to induce the requestor to accept thebooking. Thereafter, the edited booking request is sent to theallocation module at step 1021 and at step 1064 the optimisationalgorithm processes the booking request. Thereafter, the requestor mayhold the booking request temporarily at step 1019. The requestor(customer) details and/or additional information are subsequentlycaptured (either by the requestor entering information or autonomouslyfrom a customer database) at step 1029, the booking request is allocatedat step 1033 and receipt of the booking is sent to the customer at step1035 after which the process ends at step 1025.

If the requestor either joins the waitlist at 1011 or cancels thebooking request the process ends at step 1025.

Referring to FIG. 10e , there is shown a continuation of the flowchartof FIG. 10b illustrating a process flow for a widget arranged to operatewith an embodiment of the invention. Once the optimisation algorithm hasprocessed the booking request at 1064 of FIG. 10b , the requestor mayhold the booking request temporarily at step 1049 or the booking requestmay not be allocated at step 1039.

If the booking request is held temporarily, the requestor (customer)details and/or additional information are captured (either by therequestor entering information or autonomously from a customer database)at step 1059, the booking request is allocated at step 1063 and receiptof the booking is sent to the customer at step 1065 after which theprocess ends at step 1067.

Alternatively, following on from the booking not being allocated at step1039, all alternative promotions available to the requestor are filteredaccording to constraint information at step 1041 and displayed at step1043. The alternatives may be an alternative menu at step 1045, a timelimited promotion at step 1047, a backfill promotion at 1053 or acancellation of the booking request at step 1055. If the alternativemenu at step 1045 is accepted, the edited booking request is sent to theallocation module at step 1051 and at step 1061 the optimisationalgorithm processes the booking request. Thereafter, the requestor mayhold the booking request temporarily at step 1049. The requestor(customer) details and/or additional information are subsequentlycaptured (either by the requestor entering information or autonomouslyfrom a customer database) at step 1059, the booking request is allocatedat step 1063 and receipt of the booking is sent to the customer at step1065 after which the process ends at step 1067.

If the time limited promotion at step 1047 is chosen, the edited bookingrequest is sent to the allocation module at step 1051 and at step 1061the optimisation algorithm processes the booking request. Thereafter,the requestor may hold the booking request temporarily at step 1049. Therequestor (customer) details and/or additional information aresubsequently captured (either by the requestor entering information orautonomously from a customer database) at step 1059, the booking requestis allocated at step 1063 and receipt of the booking is sent to thecustomer at step 1065 after which the process ends at step 1067.

If the backfill promotion at step 1053 is chosen, the edited bookingrequest is sent to the allocation module at step 1051 and at step 1061the optimisation algorithm processes the booking request. Thereafter,the requestor may hold the booking request temporarily at step 1049. Therequestor (customer) details and/or additional information aresubsequently captured (either by the requestor entering information orautonomously from a customer database) at step 1059, the booking requestis allocated at step 1063 and receipt of the booking is sent to thecustomer at step 1065 after which the process ends at step 1067.

If the requestor cancels the booking request at step 1055 the processends at step 1067.

Referring to FIG. 10f , there is shown a continuation of a flowchartillustrating a continuation of the process flow from FIG. 10c for awidget arranged to operate with an embodiment of the invention. Therequestor may select the booking duration extension option at step 1070.If so, the booking duration extension value is selected at step 1060 andthe process continues to step 1062. If not, the process continuesdirectly to step 1062.

At step 1062, the booking step containing all constraints is sent atstep to the allocation module, and the optimisation algorithms processthe booking request at step 1064. The booking request is either be heldtemporarily at step 1019 or not allocated at step 1007.

If the booking request is held temporarily, the requestor (customer)details and/or additional information are captured (either by therequestor entering information or autonomously from a customer database)at step 1029, the booking request is allocated permanently (i.e. cannotbe altered by the algorithm in a future reallocation) at step 1089 andreceipt of the booking is sent to the customer at step 1035 after whichthe process ends at step 1025.

Alternatively, following on from the booking not being allocated at step1007, a popup will appear, stating that the requested table is notavailable at step 1081. The requestor can then request an alternativetable at step 1095, in which case the process will loop back to processline 4 of FIG. 10 c.

Alternatively, the requestor either joins the waitlist at 1011 orcancels the booking request at step 1013 and in both cases, the processends at step 1025.

Referring to FIG. 11a , there is shown a process flow of a self-seatingapp 1132 interacting with a system in accordance with an embodiment ofthe invention. The app 1132 interacts with the ResButler system via thevenue login database 1104 and the venue database 1106 in a remotecomputing system (generically referred to as the cloud 1102). A bookingrequestor (user 1100) can either select a self-seating process 1108 or abooking process 1110.

If the user selects the self-seating process the user enters a referencevalue for identification purposes at 1116 and a floor plan is displayedat 1126, after which a user may choose to return to the entry point atstep 1130 at any time convenient to the user.

If the user selects the booking process at step 1110, the app loads abooking widget 1112 and the user can then create a booking at step 1114(in accordance with the general process flows shown at FIGS. 10a-10f ).If the booking request is successful at step 1118 the user proceeds tostep 1126 at which time a floor plan is displayed at 1126, after which auser may choose to return to the entry point at step 1130 at any timeconvenient to the user.

If the booking request fails at step 1120 the user can either elect tojoin a waitlist at step 1122 or cancel the booking request at step 1124,after which a user may choose to return to the entry point at step 1130at any time convenient to the user.

Referring to FIG. 11b , there is shown an architecture diagram of thesystem in accordance with an embodiment, as related to the relationshipbetween the venue database 1134 and the website 1140, kiosk 1144 andself-seating app 1148. The general venue floor plan 1136, via theallocation process 1138, is communicated to website 1140, kiosk 1144 andapp 1148, and respectively displayed on each device (1142, 1146 and 1150respectively).

Referring to FIG. 12a , there is shown an architecture diagramillustrating aspects of a product tree structure utilised in theallocation and yield determination algorithm in accordance with anembodiment of the invention. An aspect of the ResButler system 1201 isthe product tree structure and associated logic which is arranged todetermine yield and allocation. It is accessed via a user interface1202, which includes a product input and set up interface 1200 which isarranged to modify information in the product tree and structure 1204,which includes a plurality of individual products 1206. The interface1202 also allows access to a menu setup interface 1208 which includes amenu structure, format and layout section 1210, which allows for thedesired display of menus on in-venue ordering devices 1212, the bookingwidget 1214 and the menu pre-ordering widget 1216. Each of devices 1212,1214 and 1216 are also in communication with a kitchen/bar display 1218,a booking diary 1220 (which in turn is in communication with a revenueand POS system 1226 and a third-party payment gateway 1224. Thepre-ordering app 1216 is also in communication with a pre-order paymentsaccount 1222 and a third-party payment gateway 1224.

Referring to FIG. 12b , there is shown an example screen of a listing ofproducts, specifically a “leaf” 1240 of a branch of the treerepresenting a specific product group. The Product information includesa product name 1236, a listing of prices 1248, and a specific price1250.

Referring to FIG. 12c , there is shown, in more detail, the product 1236of FIG. 12b . The product includes a number of information items 1232,which allow the product to be costed and to be reordered as required.

Referring to FIG. 12d , there is shown in more detail, the product 1236of FIG. 12b . The product includes a number of menu display settings1234, which allow the product to be displayed on a menu in the mannerdesired.

Referring to FIG. 12e , there is shown there is shown an input screenfor constraint information relevant to a specific product. Menu item(1236) can be associated with a price structure 1248, including aspecific price 1250, or a percentage adjustment 1252 from the pricingstructure 1262. There may also be provided other options such as theability to round a figure to a nearest whole dollar amount (1254 and1256) and the ability to adjust prices dependent on a particular day ofthe week and time of the day (service period) by amending the values intable 1246.

Referring to FIG. 12f , there is shown there is shown an example screenof a listing of tables in a class, specifically a “leaf” 1242 of abranch of the tree representing a specific table. The table informationincludes a description 1244 and a specific price 1260.

Referring to FIG. 12g , there is shown an input screen for constraintinformation relevant to a specific table. Table 15 (1244) can beassociated with a price structure 1262, including a specific amountspend per chair 1260, or a percentage adjustment 1252 from the pricingstructure 1262. There may also be provided other options such as theability to round a figure to a nearest whole dollar amount (1254 and1264) and the ability to adjust prices dependent on a particular day ofthe week and time of the day (service period) by amending the values intable 1246.

Advantages

The embodiment and broader invention described herein provides a numberof advantages.

Firstly, the embodiment provides an optimised space allocationinstruction set to a user associated with a venue. For example, if thevenue is a restaurant, currently the space allocation and arrangement oftables within the space of the venue is currently performed by therestaurant staff, manager or maître d'. Given the number of possiblearrangements and permutations that are possible in a venue with multiplespaces and multiple tables, which can be arranged in multiple ways, anyarrangement that is performed “manually” (i.e. a person decides how toarrange the tables) is statistically very likely to be sub-optimal,particularly since the number and size of bookings that will be received(or the time/order/rate at which they will be received) for a serviceperiod cannot be known precisely until a short time before the servicetime. Generally, any arrangement of the venue is based on the experienceor preference of the person performing the space allocation andarrangement of tables, and is therefore solely dependent on theexperience, knowledge, ingenuity and interest of the person performingthe space allocation. Therefore, the computer system of the presentinvention provides a new, mathematically and logically rigorous means ofoptimising the use of a venue.

Furthermore, the embodiment also provides additional advantages as theoptimisation of the use of the venue can be modified to maximise certaindesired outcomes. For example, the rules of the iterative allocationprocess can be varied to maximise the number of bookings to maximiseprofits. Alternatively, the iterative allocation process in accordancewith the embodiment can be varied to increase customer experience byallocating a specific use of space at a requestor's request or ensuringthat the arrangement of space is optimal for user atmosphere andexperience. As will be appreciated, the computer system in the presentinvention provides for a greater level of control over any individualvariable or group of variables regarding the operation of the venue andsuch control is not possible without the ability to allocate bookings inan intelligent manner.

Moreover, as the optimised space allocation instruction sets and userdata is retained in the database, the embodiment provides a furthermeans to optimise the operation of the venue by retrospective dataanalysis. The prediction module disclosed in the present specificationis capable of predicting the allocation of space within the venue basedon past optimised space allocation instruction sets for the period oftime under analysis.

The embodiment also provides an advantage over known online reservationsystems, in that the embodiment can engage in a process of negotiationwith the booking requestor to generate an allocated booking thatbalances the constraints of the booking requestor and the venue. Inprior art systems, there no opportunity for the reservation system tointeract with the booking requestor.

For example, for a venue utilising the invention, the venue has theability to offer special deals or propose alternate requests in theevent that a booking request cannot be accommodated at first instance.Therefore, the embodiment provides a fundamental and crucial advantageover the prior art by enabling a direct two-way connection between thevenue and the booking requestor, in a manner that does not require any“manual” intervention by venue staff or management. Furthermore, asdisclosed above, the embodiment is capable of determining effectiveincentives or additional elements that may be added to enhance the useof the space and present the incentives to a booking requestor in anautonomous manner. As a corollary, the incentives are not“pre-programmed”—that is, the embodiment does not merely select from alist of incentives in a sequential manner. Rather, the incentives aregenerated “on the fly” in response to a number of inputs, including butnot limited to the venue constraint information and the requestorconstraint information. In a technical sense, the embodiment acts as anintelligent agent, autonomously determining incentives that operate tobalance and maximise both the utility of the booking requestor and theyield of the venue.

From another perspective, the embodiment described herein provides auser interface that permits a sophisticated and directed interactionbetween the embodiment, acting as an intelligent agent for the venue,and the booking requestor, to accommodate a booking request in a mannerthat maximises the interests of the venue and the booking requestor.This advantage is achieved, in part, through the use of an interfacethat is dynamically adaptive by, in response to venue constraintinformation and requestor constraint information, with the ability togenerate multiple potential solutions utilising different menus, timedurations, seats, tables, pricing levels based on different times anddurations using dynamic pricing models, different rooms, and packages.

The user interface also permits food and beverage pre-orders which canbe individually paid for by different patrons that comprise a bookingrequest.

In more detail, the use of an algorithm in accordance with an embodimentallows a venue to be flexible in the manner in which to best accommodatethe booking request, as distinct from prior art systems, which are onlycapable of offering a very small number of fixed capacity solutions withregard to the solutions offered to requestors, the solutions beinglimited by a small number of simplistic constraints, such as the numberof bookings received, the size of bookings or the total number ofcustomers that can be accommodated during a booking interval or timeduring a service period.

In another aspect, the user interface and allocation module use time asa capacity constraint of the venue, which is associated with dynamicpricing as a variable that provides the correct incentive (ordisincentive) to cause the booking requestor to choose requestorconstraints that strike a balance between the utility sought by thebooking requestor, and the yield achieved by the venue.

As a corollary to the previous point, the algorithm eliminatesunnecessary gaps between tables and wasted space floor space andallocates bookings by optimising space through an algorithm thatreallocates previous bookings to ensure that the most recent bookingrequest is likely to be accepted.

In one particular embodiment, the interface provides an integratedportal via which a booking requestor may personalise their experiencewithin a venue through the concurrent booking of products and servicesnot directly offered by the venue, but which are allowed by the venue.For example, the provision of a bucket of champagne next to table to beopened on arrival, the provision of flowers and a personalised card, amagician to entertain as part of the experience, a specialty cake,and/or a box of chocolates.

The embodiment also advantageously provides a reference number to thebooking requestor to allow the booking requestor to alter and completetheir booking request at a later time without manual intervention.

The embodiment also advantageously provides the ability to subdivide aspace into sub-spaces and sections, to better segment the experiencesoffered to the booking requestor. Moreover, different classes of seatingand menu options may be offered to different classes, with correspondingdifferential pricing for each of the classes. Moreover, a table rankingsystem allows for dynamic pricing for particular tables. The ability toatomise the venue and the experience provides, in turn, the ability toallocate higher ranked booking requestors to higher ranked tables (i.e.a “better” allocation) and the ability to provide preferentialallocations to VIP customers or give SVIP's a specific preferred table.

The embodiment is capable of offering different menus at differentbooking times within a service period and for different durations withthe ability to charge a premium for bookings that wish to be allocatedto a peak period or to stay longer than the allocated time.Correspondingly, the embodiment is capable of offering a discount tobooking requestors that occupy a table for a shorter period.

The embodiment also advantageously provides the ability to reallocatebookings within a venue to maximise qualitative outcomes, such asmaximising ambience. For example, when a venue is substantially belowcapacity, allocated bookings may be evenly “spread” throughout the venueto maximise privacy and therefore maximise ambiance and experience.

The embodiment also advantageously provides an ongoing PerformanceAnalysis function, including the calculation of the capacity of thevenue as a measure of production time, performance measures such asyield, seat utilisation, and restaurant efficiency, and maintenance ofhistorical plans and layouts for performance reporting and as a futureforecasting input.

The embodiment also advantageously links to third party portals or thirdparty websites to determine further venue or requestor constraintinformation which may have an impact on the allocation of the bookingrequest. This may include, by way of example only, information obtainedfrom external websites regarding the identity of a booking requestor asa potentially influential people that can bring additional benefits tothe venue, and should therefore be accorded a “VIP” or “SVIP” status. Inan alternate example, forecasting information such as the weatherinformation may be accessed, to allow the system to determine whether anoutdoor dining area should be allocated bookings, or whether it shouldbe excluded from the allocation algorithm (for example, if rain isforecast).

The embodiment also allows for resource planning, comparisons andanalysis, including the creation of rosters, staffing benchmarks etc.,based on how the venue booking profile develops, plus reporting on theforecasted resources versus the actual resources allocated or utilised.This aspect of the embodiment also allows for forecasting bookings,booking patterns and using forecasted bookings and information to beautomatically linked to future capacity allocations so as to create a“learning and adaptive system”.

The embodiments described herein solve the restaurant capacity problemfaced by a restaurant by focusing on the optimisation of the restaurantspace available for bookings, rather than the optimisation of apre-defined list of tables and table combinations, with no functionalknowledge of the context in which the tables and table combinations arelocated.

In one embodiment, the invention, in the optimisation of a venue takesinto consideration the scale of all objects within the space and iscapable of accounting for any variation in the dimensions of any object(such as a table size or the spacing permitted between tables) “on thefly”, thereby adjusting for any impact on the optimisation outcome.

In one embodiment, the invention is arranged to maximise, optimiseand/or enhance the space within the venue while also managing theexperience of the booking requestor and offering a booking requestortotal flexibility in how to tailor their experience.

By comparison, previous systems provide little sophistication and notangible “decision making” capacity in the manner in which reservationdata is collected and used. Furthermore, previous systems create abarrier between the booking requestor and the venue manager.

The information and reporting abilities of prior art systems are limitedto information regarding the “management of tables”, such as, revenueper table, table turns and revenue per person and are incapable ofreporting on more relevant measures such as the optimisation of thecapacity, yield and revenue generated in a space. As discussedpreviously, the known prior art is based on theoretical combinatorialconstraint programming and a simplistic practical static linearcombinatorial priority list.

Embodiments of the present invention overcome limitations of the priorart, which is limited to utilising predefined tables and tablecombinations that do not allow for a booking request to be allocatedbased on qualitative constraints such as the maximisation of ambiance,the ranking of VIP's (Very Important Persons) and SVIP's (Super VeryImportant Persons), or the allocation of bookings to different classesof tables within a service period. Such parameters are incapable ofbeing incorporated, from a technical perspective, into prior art bookingsystems as they are fundamentally at odds with the static linearcombinatorial priority lists that are an essential feature of knownprior art systems.

Embodiments of the invention overcome a limitation inherent in the priorart, which does not recognise or allow for a customer to preselect aspecific space, sub-space, section, specific table or booking durationperiod.

Moreover, the prior art does not rank tables from “best” to “worst”(where the methodology used to rank tables is dynamic and changeable,taking into account a number of quantitative and qualitative aspects ofthe table and the venue), or divide a venue into different classeswithin a restaurant so as to offer the booking requestor the opportunityto customise their experience (and thereby maximise their utility) whilesimultaneously providing greater flexibility in the use of the space andthe use of the venue's resources in a way that maximises yield (or anyother desirable outcome).

Embodiments of the present invention allow for the incorporation ofadditional tables or removal of tables within a venue and can add or“swap” tables and table tops within a venue to be provided to a user sothat the user can setup the venue for the commencement of a serviceperiod.

In the allocation of furniture or tables in a space an important aspectin the optimisation process is the allocation and management of time.That is, both the time/date of the booking and also the duration of thebooking For example, a table of two consuming one course meal over athree hour period does not represent the same revenue, utility andmaximisation for the restaurant or venue's resources or capacity as atable of two that consumes a three course meal over only a two hourperiod.

In the allocation of furniture or tables in a space another importantaspect in the optimisation process is the recognition that differentperiods of time do not have the same utility or benefit due toinherently different demand profiles at different times/dates. Forexample, the demand for a table for two at 7:30 pm for dinner on aSaturday evening is in far greater demand than a table for two at 5:30pm. As such, any allocation algorithm which cannot take into account thebooking time and duration of a booking is unable to optimise theallocation of booking requests.

The prior art is incapable of managing time, even though time is a keydeterminant in the optimisation a restaurant's yield and also of abooking requestor's utility. Specifically, the prior art solutions havean inherent structure which precludes the ability to provide (orrecommend) multiple time periods or time periods of varying lengthsbased on the menu and/or courses that will be selected, occasion or sizeof booking. For example, in the prior art, all bookings are generallyset at an arbitrary “safe” time period, which represents the time thatwould be taken for the longest possible booking. This may be a hour or 2hour duration or some other single, set unit of time. The introductionof a changeable “time” dimension into an applied static linearcombinatorial priority lists as a methodology for allocating bookingwould create a situation where the computational time required toallocate some bookings would either be completely impractical, oralternatively, would simply result in the booking algorithm of the priorart being unable to allocate a booking, not due to the inherent physicallimitations of the venue, but because the algorithm is simply unable toresolve the resultant equation.

Embodiments of the present invention make allowance for differentproducts or a suite of products that a venue is capable of offering atdifferent booking intervals during a service period. For example, tooptimise revenue, a venue such as a restaurant must have informationregarding the products and services the restaurant is capable ofproviding and make allowance for other constraints that may be affectedas a result of a booking requestor requesting specific products andservices. As a simple example, a restaurant can offer an a la carte menufrom which diners can select one, two or three courses for their meal.Further, from historical knowledge of the restaurant's design, servicestandards, cooking techniques, the average time required to consume thefood etc., determine that an appropriate duration for a one course mealis 1 hour, a two-course meal 1½ hours and a 3 course meal 2 hours. Thisknowledge allows the allocation module and the requestor user interfaceto allocate appropriate resources, but more importantly, allows theallocation module to determine whether a booking can be allocated andsubsequently adequately serviced. The prior art is fundamentallyincapable of performing such a sophisticated determination. In the knownart, most restaurants choose an arbitrary “safe” meal duration time, theduration time being selected such that it encompasses the longestreasonable duration (e.g. two hours) so that the probability ofconflicting bookings is minimised. However, this limitation incorporatesan inefficiency into the booking process which disadvantages both therestaurant (as the restaurant is inherently limited in the number ofallocations that can be offered) and the booking requestor, who is onlyable to make a booking within the limited constraints provided by therestaurant. The embodiment described herein ameliorates this problem byproviding a system which is capable of “negotiating” an outcome thatmaximises the utility of the booking requestor while simultaneouslymaximising the yield of the restaurant.

Embodiments of the invention include the ability to offer alternativesto a booking requestor. For example, the embodiment is able to advise abooking requestor that a two hour period is not available for theirbooking preferred booking time a 1½ hour booking is available shouldthey be satisfied with a two course meal. In other words, the system iscapable of attempting to negotiate a suitable compromise position withthe booking requestor, thereby increasing the likelihood of securing thebooking, while also maximising the utility to the booking requestor,within the constraints of the venue and the requestor.

Embodiments of the invention are capable of differentiating between thetimes that are required or should be offered for different menus,different courses or different offerings so that the amount of timerequired by a booking can be optimised thereby optimising the use of thespace.

Embodiments of the invention provide allowance for the time that wouldbe taken to reset a table after use for the arrival of the next booking.For example, in a fine dining restaurant after a dining booking hascompleted its dinner paid the bill and left the table a wait personwould take away the bill folder, used napkins, used table cloth, sugarand coffee cups, and then bring back a fresh table cloth, new napkins,new water and wine glasses, new cutlery etc., to set up the table beforea new booking could be seated. This process varies for differentrestaurants and styles of restaurants and is a mandatory considerationin the process of re-using a table for a further seating. It may alsovary for the same restaurant based on the staffing levels for theparticular service.

Embodiments of the invention include a user defined dual calendar set upand permit the user to define the start and end dates for a week, and/ordefine what the start and end dates are for a period/“month”, and/or howmany periods/“months” there are in a year or what the start date and enddates are for the user defined “year” to coincide with a user'saccounting year, user's fiscal year or other requirements. Further theprior art does not include a dual calendar which has the capacity toredefine start and end dates or to define arbitrary periods of time thathave meaning to the end user, such as “current week” or “last week”,last period/“month” or “current week versus “same week last year”, whichmay not have a universal meaning but which are critical for specific usecases in specific industries, and allow for correct reporting, reviewand forecasting.

Embodiments of the invention include a multi-venue capability wherebyeach venue within a group of venues can be included in the same group.Where venues are located in different time zones, the venues correctlydisplay the correct time to avoid confusion and errors in booking timeswhen bookings are made for different venues in the same group.

Embodiments of the invention include all information and data utilisedby multi-venue groups to be available to all venues within the groupsuch that where a booking cannot be allocated to one venue in the group,the booking requestor can be offered a different nearby venue in thegroup. Similarly, booking constraint information utilised in booking onevenue can be utilised in booking another venue.

Embodiments of the invention include the ability to change the diarypage format to accommodate different activities that a restaurant maywish to undertake. For example the prior art cannot confirm a bookingfor a private room within a restaurant as; firstly the booking widgetcannot cater for the booking request; secondly, the booking widget doesnot have the ability to request the right information; and third, thediary setup cannot cater for a function booking.

Embodiments of the invention include an interface referred to as a“restaurant manager's page” or a “dashboard” which is analogous to apilot's cockpit where the interface layout is organised so that allrelevant information is either visible or immediately accessible,thereby allowing greater efficiency during a busy service period due tominimal information being place on separate screens and/or pop-ups.

Embodiments of the invention review the actual revenue received againsta calculated “maximum potential revenue” to determine the level ofdiscounting (explicit or implicit) that was applied to achieve theactual revenue gained. This metric, termed the “revenue yield” is ameasure of the revenue achieved versus the total possible revenue whereall sales and complementary items are calculated at full price.

Embodiments of the invention calculate and monitor actual bookingduration times (rather than utilising hypothetical or fixed bookingduring times) and the duration times can be analysed by menu, by coursesselected, by occasion, by group size, wherein the resultant analysis canbe used as an input to determine appropriate allocations for bookingtimes and benchmarks for forecasting rather than a simplisticgeneralisation provided by the prior art.

Embodiments of the system advantageously allow for the forecasting ofpotential revenue, profit, etc., utilising algorithms that optimise forthe best use of available resources, given a specific pool of bookingrequests (both historical and projected).

Moreover, embodiments of the invention are intuitive in that thealgorithms encoded in the system assist in the forecasting of futureevents, demand and provide feedback which enables the furtherdevelopment of capacity and revenue generation.

Embodiments of the invention advantageously interrogate any unused orunallocated spaces or tables and automatically notify potential bookingrequestors of the availability, potentially applying a dynamic price tosuch promotions and thereby increasing yield and optimising use ofavailable resources.

Embodiments advantageously allow a booking requestor to make one bookingrequest to book two allocation portions within the same venue. Forexample, where the venue is a restaurant, the requestor may book a seatat the bar for 7 pm and a table in the main dining room for 7:30 pm.

Embodiments advantageously allow a booking requestor to book two venuesthrough the one interface. For example, the interface allows the bookingrequestor to book a show or a theatre and book a table in a restaurantthrough the same booking request.

The embodiment, from a technical perspective, is able to utilise thesize and floor space of the restaurant and its spatial characteristicsto determine which tables or areas have a higher utility than others orwhere to place tables. Furthermore, the embodiment is capable ofsegmenting the restaurant into multiple areas (where an area can alsocomprise a separate room, a separate level and any venue can be splitinto multiple areas irrespective of physical barriers such as wallswithin the venue) which can then be further divided into subspaces,sections and or classes for the allocation of bookings. Specifically,the prior art is unable to recognise different areas beyond simplenumbering or table referencing.

The embodiment advantageously allows for a variable number of tables tobe included within a restaurant during the booking allocation process.The embodiment can add or remove any tables, as it is capable ofdefining the space.

The prior art requires the manual determination of a finite list of“tables and table Combinations” which are then required to be manuallyinputted into the system and which then form the total solution poolfrom which a booking can be allocated to. This means that there is nocheck and balance that all potential solutions have been manuallyidentified and inputted into the system that forms the total solutionpool. The embodiment creates a unique solution for each set of bookingsfor a service period based on the bookings received and the bookingsexpected from “walk-in” customers. The embodiment is not bound by apredetermined manually inputted list of tables.

The prior art is agnostic as to the difference between the differentcompositions of “tables” and “table combinations” and the concept of(“fixed tables”) and (“flexible tables”) in that the composition andratio of fixed versus flexible tables impacts on the ability to organisetables and allocate bookings in the optimisation of the floor space of arestaurant.

The embodiment dynamically allocates bookings whereby all bookings canbe considered together for a more efficient or dynamic allocation to beachieved. The prior art only considers dynamic booking allocationthrough the application of a “constraint programming” technique. Thisprior art technique, by definition, is incapable of optimising space,plus is computationally inefficient and not practical.

Constraint programming is similar to static allocation in that it cannotoptimise a space as it suffers from the same limitations, specifically:

-   -   i. The solution is limited to a pre-determined fixed number of        tables;    -   ii. From the fixed number of tables, a solution set is developed        comprising a list of tables and table combinations;    -   iii. It cannot add or remove tables during the booking        allocation process to optimise the number of booking that can be        taken;    -   iv. It can merely search and select a table or table combination        that is not utilised from which to allocate a booking; and    -   v. The constraint program, by definition, is a search program        and hence does not have the ability to create a solution.

The embodiment advantageously allocates bookings and, at a later time,reallocate the bookings received and allocated to tables to determine ifadditional tables can be incorporated within or removed from thesolution set so that the total capacity offered is increased

The embodiment is not restricted to the use of a define set of tablesand table combinations—one set of tables and table combinations can beutilised before service and a different set of tables and tablecombinations with different priorities can be used during service.

There are computational inefficiencies inherent in linear and staticallocation processes of the prior art which result in poor allocations,which in turn require considerable manual intervention to ensure priorbookings do not hinder subsequent booking requests from being allocated.

The static allocation process of the prior art cannot offer anyacceptable or measurable level of maximisation or optimisation ofrestaurant floor space as the prior art has no mechanism or algorithm bywhich the relationship of furniture to floor space can be determined. Atbest the prior art can only allocate bookings within the selected andmanually determined total population of “tables and table combinations”.As such the prior art has no inherent technical character, in that no“determination” of an optimal allocation is performed, but rather thereis simply a matching based on a simplistic lookup table. The embodimentis inherently technical because it is directed to solving a “real world”problem of how to arrange furniture to optimise a space, not simplyallocate bookings to a random table.

The prior art cannot “create” or remove tables on a restaurant's floorplan as required by bookings. Again, the embodiment is capable ofassessing the spatial limitations of the space and add or remove tablesas necessary.

The prior art cannot take into account any characteristics of thebooking requestor (customer) or of the physical space, and thereforecannot autonomously allocate a booking for a higher ranked customer to ahigher ranked table, class, space, subspace or section.

As the prior art has no “spatial awareness”, the prior art has noinherent ability to offer specific tables or class of tables withguaranteed seating at those tables or classes, with or withoutadditional constraints. The embodiment is capable of guaranteeing anallocation to a specific table, even in circumstances when a specifictable is allocated.

Moreover, as a corollary, the prior art cannot prioritise bookingrequests by areas (e.g. sub-spaces, sections, etc.) within a restaurant,cannot allocate bookings to multiple dining areas in a priority sequenceor concurrently, nor is the prior art capable of dynamically changingtable numbers in accordance with changes to the changes in tablelocation and allocation.

The embodiment is capable of dynamically changing floor plans in realtime for integration with other systems such as Point of Sale systems orfor operational and planning purposes.

The embodiment permits self-seating through a widget, app, kiosk or anyother device or computer.

The booking information requested and received by the embodiment isutilised to tailor the available options shown to a customer. Forexample, a person requesting to make a booking for two people for ananniversary may be shown a different menu and options to a personrequesting to make a booking for 6 people and two children. Suchvariations are not provided based solely on the provision of multiplemenus, etc., but on whether the restaurant is resourced to provide suchoptions.

The prior art does not allow you to book two areas within the samerestaurant within the same booking so that a person can have more thanone experience within the one venue. For example, a seat at the barfollowed by a table in the dining room.

The embodiment is capable of developing more than one floor plan ortable orientation or table layout or modify constraints during thebooking allocation process to optimise outcomes in accordance withselected constraints which define the strategy of the venue. The dynamictable allocation aspects of the prior art are theoretical and requirebespoke theoretical solutions that also require expensive maintenancefrom specialised mathematicians and computer programmers. The embodimentdescribed herein is a technical solution to a technical problem that hasnot been solved by the prior art.

The prior art does not permit or teach different optimisation solutions,algorithms or priority lists for different combinations of bookingrequests received to permit greater optimisation. The embodimentprovides different optimisation rules and algorithms that take theavailability of resources into account such as permitting some bookingsto be reallocated while keeping other bookings fixed on allocation of anew booking request if it will permit a better outcome.

The embodiment is capable of limiting the size of bookings within aspace, subspace, and/or section to ensure that the flexibility of anarea, subarea or section to take additional bookings before or afterthat booking and the optimisation of that area, subarea, section or thewhole venue is not compromised

The embodiment is capable of “spreading” a booking over one or moretables, table combinations, spaces, subspaces or sections to ensure thatthe booking allocations within a venue are optimised.

The embodiment is capable of creating table allocation patterns or rulesfor greater efficiency to allow or permit a better utilisation oroptimisation of the venue, space, subspace, section or class;

The prior art does permit the creation of different classes within arestaurant and does not permit those classes to be of flexible size,such that, the area, subarea, section which may comprise those differentclasses and the number of tables that can be allocated to these classescan remain variable and adjust during the booking allocation processbased on the demand and requests for tables within those differentclasses.

The embodiment is capable of optimising for qualitative outcomes, suchas for ambiance, for example by leaving an empty table between allocatedtables when the restaurant is not full to offer greater privacy.

The embodiment advantageously is capable of discriminating betweendifferent circumstances and customers, such that the embodiment mayautonomously determine which particular menus and/or courses are to beoffered for a service period and for booking intervals within thatservice period.

The embodiment is capable of strategically controlling capacity within avenue, using any one of a number of resources/constraints, includingmenu, courses, occasion, time duration, subs-space or section, class,etc.

The embodiment, by tracking the use of tables and or areas to determinepopular or sought-after areas, is capable of applying dynamic pricing.

The embodiment is capable of utilising information provided by acustomer when making a booking request to provide recommendations to theperson making the booking request. For example, if a customer were toadvise the occasion for their booking was their anniversary and thebooking was for two people, menu recommendations and table selectionsoffered could be completely different to the menu and the tableselection offered to a table for two having a business meeting on a timelimit. The prior art cannot compare recommendations and autonomoussettings by the system compared to manual settings and manual over-ridesand evaluate which solution and outcome was better and makerecommendations and further adjustments.

The prior art cannot calculate revenue yield as the actual price ofitems versus the recommended price for each item including therecommended price of the complementary items provided, and moreover, theprior art cannot determine the efficiency factor of each area, subareaand section. The efficiency factor being the revenue yield (actualrevenue divided by possible revenue being the total revenue that couldhave been achieved if all items provided including any complimentaryitems were sold at their full recommended retail price) multiplied bythe seat occupancy (time seats are utilised divided by the time seatsare available for use) as a percentage.

The embodiment is capable of determining the optimum ratio of fixedversus flexible seating and updates the ratio based on historicalinformation of unfulfilled booking requests in order to minimise futurebookings that cannot be accepted.

The embodiment may include sensors associated with each table for eachpotential seating position so that the embodiment can detect when allguests have arrived and use that information to send pre-ordered foodand drink orders to the kitchen and bar respectively so that preparationcan begin.

The prior art does not permit a pre-order made in conjunction with abooking request to be completely integrated as part of the Point of Sale“product tree” for stock control and for printing or display of theorders in the kitchen or bar for preparation of those orders includingstock decrementing.

The embodiment advantageously provides a dashboard, designed as a“cockpit” such that all relevant information is visible on the screen atall points in time including a communications panel including a dynamicfloor plan and Gantt chart.

The embodiment is advantageously capable of delaying the firstallocation of booking requests to the tables and table combinations aseach individual booking request is allocated on receipt of that bookingrequest. Specifically, the embodiment delays the first allocationprocess until a certain “threshold” target is reached. The process ofallocating each booking as soon as it is received does not offer anybenefits and creates “barriers” to the acceptance of subsequentbookings.

The embodiment advantageously capable of classifying tables and tablecombinations into different categories such that individual bookingrequests can be applied to different categories and a different priorityand allocation process which may include the process of a guaranteedallocation to a specific table not permitted by the prior art.

The system advantageously provides a table configurator and simulator todetermine the optimal size table, quantity of tables, orientation ofseating, size and quantity of fixed versus flexible seating, to therebybe used in the planning of a restaurant or in the revision of arestaurant arrangement.

The embodiment advantageously allows for dynamic variations in capacity,thereby maximising efficient use of resources.

Dynamic variation may be coupled with yield management, as the system iscapable of utilising yield management techniques to optimise bookings,and also to provide a better, more customised service to the bookingrequestor. Yield management is performed, in part, by an understandingof the products and services available to the requestor, wherein thesystem uses constraint information to optimise for various constraintswhile maximising yield.

Disclaimers

Throughout this specification, unless the context requires otherwise,the word “comprise” or variations such as “comprises” or “comprising”,will be understood to imply the inclusion of a stated feature or groupof features but not the explicit exclusion of any other feature or groupof features.

Those skilled in the art will appreciate that the embodiments describedherein are susceptible to obvious variations and modifications otherthan those specifically described and it is intended that the broadestclaims cover all such variations and modifications. Those skilled in theart will also understand that the inventive concept that underpins thebroadest claims may include any number of the steps, features, andconcepts referred to or indicated in the specification, eitherindividually or collectively, and any and all combinations of any two ormore of the steps or features may constitute an invention.

Where definitions for selected terms used herein are found within thedetailed description of the invention, it is intended that suchdefinitions apply to the claimed invention. However, if not explicitlydefined, all scientific and technical terms used herein have the samemeaning as commonly understood to one of ordinary skill in the art towhich the invention belongs.

Although not required, the embodiments described with reference to themethod, computer program, computer interface and aspects of the systemcan be implemented via an Application Programming Interface (API), anApplication Development Kit (ADK) or as a series of program libraries,for use by a developer, for the creation of software applications whichare to be used on any one or more computing platforms or devices, suchas a terminal or personal computer operating system or a portablecomputing device, a smartphone or a tablet computing system operatingsystem, or within a larger server structure, such as a ‘data farm’ orwithin a larger computing transaction processing system.

Generally, as program modules include routines, programs, objects,components and data files that perform or assist in the performance ofparticular functions, it will be understood that the functionality ofthe method, computer program and computer interface defined herein maybe distributed across a number of routines, programs, objects orcomponents to achieve the same functionality as the embodiment and thebroader invention claimed herein. Such variations and modifications arecontemplated by the inventor and are within the purview of those skilledin the art.

It will also be appreciated that where methods and systems of thepresent invention and/or embodiments are implemented by computingsystems or implemented across multiple computing systems then anyappropriate computing system architecture may be utilised withoutdeparting from the inventive concept. This includes standalonecomputers, networked computers and dedicated computing devices that donot utilise software as it is colloquially understood (such asfield-programmable gate arrays).

Where the terms “computer”, “computing system”, “computing device” and“mobile device” are used in the specification, these terms are intendedto cover any appropriate arrangement of computer hardware forimplementing the inventive concept and/or embodiments described herein.

Where the terms “software application”, “application”, “app”, “computerprogram”, “program” and “widget” are used in the specification whenreferring to an embodiment of the invention, these terms are intended tocover any appropriate software which is capable of performing thefunctions and/or achieving the outcomes as broadly described herein.

Where reference is made to communication standards, methods and/orsystems, it will be understood that the devices, computing systems,servers, etc., that constitute the embodiments and/or invention orinteract with the embodiments and/or invention may transmit and receivedata via any suitable hardware mechanism and software protocol,including wired and wireless communications protocols, such as but notlimited to second, third, fourth and fifth generation (2G, 3G, 4G and5G) telecommunications protocols (in accordance with the InternationalMobile Telecommunications-2000 (IMT-2000) specification), Wi-Fi (inaccordance with the IEEE 802.11 standards), Bluetooth (in accordancewith the IEEE 802.15.1 standard and/or standards set by the BluetoothSpecial Interest Group), or any other radio frequency, optical,acoustic, magnetic, or any other form or method of communication thatmay become available from time to time.

Claims

Annexure 1

Prior Art

-   -   RevPASH (Revenue Per Available Seat Hour)    -   CMPASH (Contribution Margin Per Available Seat Hour)    -   RevPASM (Revenue per Available Square Meter)    -   ProPASH (Profit per Available Seat Hour)    -   ProPASM (Profit per Available Square Meter)    -   RRM (Restaurant Revenue Management)    -   Time Per Table Turn    -   Times Table Turn    -   Cancelled/No Show/Covers as a % of Reserved Covers    -   Average revenue per person

Note:

The use of single measures applied to PASH and PASM do not offerinformation as to what inputs need to be changed, how they need to bechanged or other information that would assist a person in theirdecision making process or provide the necessary information that couldbe used within an artificially intelligent system for the autonomouschanging of constraints.

Annexure 2

Examples of Performance Indicators for Restaurant Management, YieldManagement, Efficiency and Metrics for Forecasting and ArtificialIntelligence for Autonomous Constraint Changes

To date too much reliance has been placed on a few single dimensionmetrics such as table turns, average spend per customer and revenue peravailable seat hour, which, in themselves, do not offer any guidance asto what decisions a restaurant should take. This has resulted inrestaurants being limited to and merely focusing on discounting pricesduring low demand periods.

Revenue Yield

-   -   AR (Actual Revenue)—Used by prior art to calculate RevPASH    -   PR (Potential Full Revenue—all items sold and free items        provided at RRP)    -   RY (Revenue Yield)

Seat Capacity (Production) and Utilisation

Capacity

-   -   ASH (Available Seat Hours)—Capacity—Used by prior art to        calculate RevPASH

Revenue

-   -   RSH (Revenue Seat Hours)—Equivalent to the prior art of RevPASH

Utilisation

-   -   SUF (Seat Utilisation Factor)

Efficiency

-   -   SEF (Efficiency Factor—Revenue Yield (RY) multiplied by (SUF))

Costs

-   -   Cost levels can be calculated by available seat capacity or        revenue seat capacity

Table Capacity (Production) and Utilisation

Capacity

-   -   ATH (Available Table Hours)

Revenue

-   -   RTH (Revenue Table Hours)

Utilisation

-   -   TUF (Table Utilisation Factor)

Efficiency

-   -   TEF (Table Efficiency Factor)

Costs

-   -   Costs levels can be calculated by available table capacity or        revenue table capacity

Units of Capacity

Units of Measure

-   -   NOR (Number of Restaurants)    -   NOT (Number of Tables)    -   NOS (Number of Seats)

Hours Open

-   -   HRO (Hours Restaurant Open)    -   HKO (Hours Kitchen Open)

Service Periods Open

-   -   SPO (Service Periods Open)    -   BPO (Breakfast Periods Open)    -   LPO (Lunch Periods Open)    -   DPO (Dinner periods Open)    -   SPO (Supper Periods Open)

Service Hours Open

-   -   BSHO (Breakfast Service Hours Open)    -   LSHO (Lunch Service Hours Open)    -   DSHO (Dinner Service Hours Open)    -   SSHO (Supper Service Hours Open)

Back of House (Kitchen) Hours

-   -   HKP (Hours Kitchen Preparation)    -   HKS (Hours Kitchen in Service)    -   HKC (Hours Kitchen Clean-up)

Front of House (Dining Room) Hours

-   -   HDRP (Hours Dining Room Preparation)    -   HDRO (Hours Dining Room Open)    -   HDRC (Hours Dining Room Clean-up)

Rankings

Table and Stool ranking

-   -   Ranking of areas    -   Ranking of subareas within areas    -   Ranking of sections within areas    -   Ranking of classes    -   Ranking of all tables within the venue    -   Ranking by table characteristics; view, privacy, etc

Fixed versus Flexible Seating

-   -   Number of Fixed table    -   Percentage of Fixed Tables    -   Number of Flexible Tables    -   Percentage of Flexible Tables    -   Usage of the fixed Tables    -   Usage of the Flexible Table    -   Usage of Alternate Floor Plans and Layouts    -   Usage of additional Furniture by the optimisation algorithm    -   Removal of Furniture shown on the Floor Plan by the optimisation        algorithm    -   Number of bookings that could not be accommodated by booking        size and timing

Bookings

Booking Requests Allocated

-   -   Booking requests by time, date, etc, made that could be        accommodated by booking size by occasion, by service, by area,        subarea, section, class, specific table

Booking Profile

-   -   Booking lead time profile    -   Booking group size    -   Booking occasion    -   Booking composition by adults, by children, by high chairs, by        etc.,    -   By duration    -   By menu    -   By time    -   By Butler Service    -   By table size    -   By table requested    -   By table preferred    -   By postcode/address

Booking Requests Rejected

-   -   Booking requests by time, date, etc, made that could not be        accommodated by booking size by occasion, by service, by area,        subarea, section, class, specific table    -   Booking requests by time, date, etc, made where a person took an        alternate booking without an incentive by booking size by        occasion, by service, by area, subarea, section, class, specific        table    -   Booking requests by time, date, etc, made where a person took an        alternate booking with an incentive by booking size by occasion,        by service, by area, subarea, section, class, specific table    -   Booking Requests by time, date, etc, made that went on a        waitlist by service by time by booking size by occasion, by        service, by area, subarea, section, class, specific table    -   Booking Requests by time, date, etc, that went on a wait list        that could be accommodated by service by time by booking size by        occasion, by service, by area, subarea, section, class, specific        table    -   Booking requests by time, date, etc, made that went on a wait        list that could not be accommodated by service by time by        booking size by occasion, by service, by area, subarea, section,        class, specific table    -   Booking lead time profile    -   Booking source, by website, by third party, by app, by referral

Source of Booking

-   -   Booking source (Source of Revenue), by website, by third party,        by app, by referral    -   Cost of booking source and cost of referrals

Performance Analysis

Revenue Analysis

-   -   RRSH (Revenue per Revenue Seat Hour)    -   RASH (Revenue per Available Seat Hour)    -   RRTH (Revenue per Revenue Table Hour)    -   RATH (Revenue per Available Table Hour)    -   Revenue per Chair    -   Revenue per Table    -   Revenue Per Person    -   Revenue per person by courses, by class, by menu, by time        booked, by booking duration    -   Revenue by area, subarea, section, class and by their respective        square meters (also prorata over the whole restaurant)    -   Revenue by additional restaurant items, by area, subarea,        section, class, table    -   Revenue by supplementary items, by area, subarea, section,        class, table    -   Revenue by table type    -   Revenue by Table number    -   Revenue per Total Hours including prep and closing up    -   Revenue per Kitchen Hour (Kitchen Hours—Open Hours)    -   Revenue by Front of House Hours (Front of House Hours—Open        Hours)    -   Customer Retention rate (Total Customers—Total New Customers)        divided by total Customers    -   By time of Booking    -   By seating    -   By repeat versus new customers    -   By type of Customer    -   Revenue During peak Times    -   Revenue During Non-Peak times    -   Revenue During Shoulder Periods    -   Average spend per customer by all metrics    -   Times Tables Turn (total duration times divided by the number of        people)    -   Function Revenue (also as a 5 of total revenue)    -   Home delivery as a % of total Revenue    -   Take Away as a % of total Revenue

Customer Analysis

-   -   Customers per Service    -   Customers by booking time, by service, by day    -   Customers by menu, by course, by class, by area, by subarea, by        section, by day    -   Customers by occasion    -   Customers by group size    -   Customers with Supplementary Items and by Supplementary items    -   Customers without Supplementary Items    -   Customers by duration booked prior to the service requested    -   Customers by booking source    -   Customers by promotion    -   Customers by Average Spend    -   Loyalty Members Average Spend    -   Average Spend by member type    -   Repeat Customers by average spend    -   New Customers by Average Spend    -   Average spend by individual type, adult, child, high chair    -   Total customers versus repeat customers versus new customers

Duration Time Analysis

-   -   Duration time by booking size    -   Duration time by booking size by menu    -   Duration time by booking size by menu by number of courses    -   Duration time by booking size by customer type    -   Duration time by booking size by day    -   Duration time by booking time interval by day    -   Duration times by booking size by menu, by time taken for each        activity, being seated, taking food order, taking drink order,        time taken for the first course to be prepared, time taken for        the first course to be consumed, time taken for the second        course to be delivered from time of seating and from time to        being called away, time to consume the second course, time third        course order taken, time before third course delivered, time to        consume third course, other items ordered, time other items        delivered, time bill given, time bill paid.    -   Duration times by occasion using the same metrics as booking        size    -   Table reset times by table type by day of the week by time.

Product Mix Analysis

Food (by time, by service, by day, by server)

-   -   A la Carte One Course    -   Two Courses    -   Three Courses    -   Degustation Menu    -   Pre Theatre Menu    -   Post Theatre Menu    -   Promotional Menus    -   Take away revenue    -   Home Delivery revenue

Beverage (by time, by service, by day, by server)

-   -   Alcoholic Beverage Revenue    -   Non-Alcoholic Beverage Revenue    -   Soft Drink Revenue    -   Tea & Coffee revenue

Supplementary (by time, by service, by day, by server)

-   -   Window seat surcharge    -   Preferred booking time surcharge    -   Extended Time Surcharge    -   Booking Fee    -   Gift box    -   Chocolates    -   Roses    -   Other retail items, books, oil,    -   Room Hire Charges

Tables

-   -   Booking size mix by day by service, by area, by subarea, by        section    -   Booking size mix by occasion    -   Booking size mix by product    -   Requested tables    -   Usage and Occupancy of Requested tables    -   Rates of Requested tables versus other tables    -   Revenue of Requested tables versus other tables    -   Preferred Tables    -   Usage and Occupancy of Preferred Tables    -   Rates of Requested Tables versus other tables

Staff Analysis ad Roster Parameters

Staff Analysis and Ratios

-   -   Kitchen staff per customer (ratio)    -   Kitchen Staff Hours per customer    -   Kitchen Hand per customer (ratio)    -   Kitchen Hand Hours per customer    -   Wait staff per customer (ratio)    -   Wait staff hours per customer    -   Food Runner per customer (ratio)    -   Food Runner hours per customer    -   Bar Staff per customer (ratio)    -   Bar Staff hours per customer    -   Food Runner per customer (ratio)    -   Food Runner Hours per customer    -   Reception staff per customer    -   Reception Hours per customer    -   Kitchen preparation times to tables and customer ratios    -   Set-up times to tables and customer ratios

Break Even and Cost Analysis

Break-Even Analysis

-   -   BESUF (Breakeven Seat Utilisation factor)    -   BERSH (Breakeven Revenue Seat Hours)    -   BERPH (Breakeven Revenue per Hour)    -   BERPP (Breakeven revenue per Person)    -   BERPT (Breakeven Revenue per Table)    -   BEASH (Break Even per Available Seat Hour)    -   BERY (Break Even Revenue Yield)

Cost Analysis Ratios and Percentages

-   -   Menu Costings    -   Mark-up per menu item as a percentage    -   Mark-up per menu item as a dollar value    -   Food COGS (Split by venues and courses)    -   Alcohol Beverage COGS    -   Non-Alcoholic Beverage COGS    -   Tea and Coffee Beverage COGS    -   BH Wages Gross (Wages split by preparation, by service and by        clean-up)    -   BH Wages On-Costs    -   BH Wages Total Costs    -   FH Wages Gross (Wages split by preparation, by service and by        clean-up)    -   FH Wages On-Costs    -   FH Wages Total Costs    -   Operational Costs    -   Entertainment Costs    -   Marketing Costs    -   Utility Costs    -   Premises Costs    -   Ownership Costs    -   Head Office Costs    -   Inventory Turnover    -   Overhead Rate per metric    -   Customer Acquisition Cost (Marketing Variable Costs divided by        Total New Customers)    -   All cost categories by: (per Available Seat Hour)    -   (per Revenue Seat Hour)    -   (per Available Table Hour)    -   (per Revenue Table Hour)    -   (Opening Hours versus total kitchen Hours)    -   (Open Hours versus total Front of House Hours)

Supplier Pricing

-   -   Pricing by suppliers for the same item    -   Reliability of Suppliers    -   System to select the cheapest supplier to send the order to

Spacial Guidelines and Measures

Floor Space Mix

Total Floor Plan Area (100%) Kitchen Floor Plan Area (30%) Wash Up StoreRoom, Locker Room, Admin Floor Plan (10%) Area Dining Room and Bar PlanArea (includes toilets and (60%) waiters stations)

Dining Room Space (Required to Scale)

-   -   Dining Room Area 1 Floor Plan    -   Dining Room Area 2 Floor Plan (etc)    -   Private Dining Room Area 3 Floor Plan (etc)    -   Dining Room Subarea 1 Floor Plan (etc)    -   Dining Room Section 1 Floor Plan (etc)    -   Bar Area Floor Plan

Area per Person Guide

Square meters per patron Fine Dining 1.70 to 1.90 square meters Squaremeters per patron Full Service Restaurant 1.10 to 1.40 Dining squaremeters Square meters per patron Counter Service 1.70 to 1.90 squaremeters Square meters per patron Fast Food Medium 1.00 to 1.30 squaremeters Square meters per patron Table Service, Hotel/ 1.40 to 1.70 Clubsquare meters Square meters per patron Banquet, Minimum 0.90 to 1.10square meters

Table Top Size Guide

Minimum recommended table top size per 0.18 square person meters Minimumtable top size (for two) 600 mm by 600 mm Table Top Fine Dining(minimum) 750 mm by 750 mm Table Top Full Service Restaurant Dining 700mm by 750 mm Casual Restaurant Full Service Dining 600 mm by 700 mm BarArea dining top 300 mm by 500 mm Round Top 1 to 2 people diameter  600mm Round Top 2 to 4 people diameter  800 mm Round Top 4 to 5 peoplediameter 1000 mm Round Top 5 to 6 people diameter 1200 mm Round Top 6 to7 people diameter 1350 mm Round Top 7 to 8 people diameter 1500 mm

Chair Size Guide

Minimum chair footprint 450 mm by 450 mm

Spacing Between Tables

Space between rectangular tables including chairs 1250 mm to 1550 mmSpace between table to table with chair only on 1050 mm one side Spacebetween back to back chairs for movement  460 mm Space between diagonalchairs  460 mm Space between tables in row seating  150 mm to 700 mmSpace between round tables 1350 mm Space allowed for chairs along atable  600 mm Walk way between table with no chairs  600 mm Walk wayfire egress depends on regulations 1000 mm

Waiter Stations

Waiter Stations up to 20 chairs/diners 0.50 to 1.00 square meters WaiterStations up to 60 chairs/diners 2.25 to 3.75 square meters

Bars Space and Bar stools

Bar Area Floor Plan Bar Stool seating Distances 510 mm to 600 mm

1. A computing system for optimising and allocating bookings within oneor more spaces in a venue, comprising: an allocation module including anoptimisation algorithm in communication with a processor and arranged toreceive at least one booking request for a table or table combinationand communicate with a database of other saved booking requests, whereinthe allocation module determines whether a predetermined threshold hasbeen exceeded, and if so, the allocation module retrieves the savedbooking requests and combines the at least one booking request with thesaved booking requests to form a pool of requests, retrieve constraintinformation regarding the tables and table combinations and iterativelyallocate each of the requests from the pool of requests to a table ortable combination utilising the constraint information to select thetable or table combination, wherein an optimised allocation instructionset of allocated bookings is produced, wherein the optimised allocationinstruction set is saved in the database and provided by a spaceallocation user interface to one or more users associated with thevenue.
 2. A computing system in accordance with claim 1, wherein thedetermination of the threshold value includes at least one of the numberof bookings received for a specific time period, a specific time period,other constraint information associated with the booking and constraintinformation associated with the booking requestor.
 3. A computing systemin accordance with claim 2, wherein the determination of the thresholdvalue is varied over time, wherein multiple thresholds are applied tore-allocate bookings.
 4. A computing system in accordance with claim 1,wherein the tables and table combinations are arranged intosub-groupings based on constraint information, wherein the allocationmodule iteratively allocates requests for each sub-grouping independentof other sub-groupings.
 5. A computer system in accordance with claim 1,wherein the allocation module is arranged to utilise constraintinformation to group at least a sub-set of tables and table combinationsin the space into different classes to create a ranking for the at leastthe sub-set of tables and table combinations.
 6. A computing system inaccordance with claim 5, wherein the allocation module utilisesconstraint information including the ranking of each table or tablecombination to allocate the booking to each table or table combination.7. A computing system in accordance with claim 1, wherein constraintinformation includes booking requestor identity information receivedfrom at least one of an internal and a third-party database ofinformation, wherein the identity information is utilised to rank one ormore booking requestors.
 8. A computing system in accordance with claim1, wherein each one of the tables and table combinations is allocated adynamically variable identifier such that each one of the tables andtable combinations retain a consistent identity regardless of therelative reconfiguration of each of the tables and table combinations ateach iteration of the optimisation algorithm, wherein the identifiersare provided to the user interface and saved in the database.
 9. Acomputing system in accordance with claim 1, wherein the allocationmodule interfaces with a menu module arranged to vary the menu availableto a booking requestor dependent on constraint information provided bythe booking requestor, the booking information including but not limitedto of the requested group size and the day and/or time of the requestedbooking.
 10. A computing system in accordance with claim 1, wherein theoptimisation algorithm, in response to the booking request, utilises thebooking request information to determine the revenue potential for aparticular combination of at least two of the menu, the group size andthe date/time of a booking, wherein the algorithm dynamically varies theoptions offered to the booking requestor to optimise the revenuepotential of the restaurant.
 11. A computing system in accordance withclaim 1, wherein the optimisation algorithm monitors a demand for one ormore of the table or table combinations utilising at least one of date,service, time, occasion and group size to calculate dynamic pricingchanges or changes to the venue to optimise the venue.
 12. A computingsystem in accordance with claim 11, wherein the user interface isarranged, in response to constraint information provided by the bookingrequestor, to provide a varied booking allocation incorporatingadditional constraint information to the booking requestor, wherein thesystem provides the option, via the user interface, for the bookingrequestor to accept the varied booking allocation or alter theadditional constraint information.
 13. A computing system in accordancewith claim 11, wherein a menu module includes a plurality of menus, eachof the menus being associated with respective menu constraintinformation, wherein a selected menu from the plurality of menus isdisplayed to the booking requestor via the user interface dependent on apreferred time period for the booking provided by the booking requestoras an element of the constraint information provided by the bookingrequestor.
 14. A computer enabled method for iteratively allocating andoptimising the use of space in a venue utilising the system inaccordance with claim 1, comprising the steps of: receiving at least onerequest to book one of a table or table combination within a spacewithin the venue from at least one requestor via the communicationsnetwork, determining whether other booking requests for the one of atable or table combination have been made by other requestors whereby,if the sum of the at least one request and the other requests exceeds apredetermined value, then information is retrieved regarding the otherrequests and information pertaining to the other requests and combinedthe at least one request to form a pool of requests, and each of therequests in the pool of requests is iteratively allocated utilisingconstraint information to produce an optimised table and tablecombination allocation instruction set, wherein the optimised table andtable combination allocation instruction set is provided to one or moreusers associated with the venue.
 15. A computing system for allocatingone or more booking requests for the provision of a service in a venueutilising the system in accordance with claim 1, the service includingthe allocation of a space within the venue and the provision of one ormore products, the system comprising: a processor arranged to execute abooking allocation software module, the module being in communicationwith a product database including product information relevant to aplurality of products, the product information for each one of theplurality of products being associated with a product capacity value;the allocation module being arranged to request product constraintinformation related to one or more constraints provided by a bookingrequestor and retrieve associated product capacity values from thedatabase, and utilise the product capacity values and product constraintinformation to determine product availability; and a user interfacearranged to interact with the requestor and provide additional productinformation and additional constraints to the requestor, wherein therequestor may one of agree to the additional constraints and requestallocation of the booking on the basis of acceptance of the one or moreadditional constraints or reject the constraints and not be allocated.16. A system in accordance with claim 15, wherein the module determinestable availability using an iterative allocation process.
 17. A systemin accordance with claim 15, wherein the module utilises qualifiedproduct information to determine table availability using theclassification of tables into categories.
 18. A system in accordancewith claim 17, wherein the module utilises the qualified productinformation to determine table availability within a space comprisingone or more spaces.
 19. A system in accordance with claim 17, whereinthe module utilises the qualified product information to determine thetable availability to effect an optimised condition.
 20. A system inaccordance with claim 15, wherein, if the product request is notconfirmed then the booking requestor is provided with at least onealternative determined utilising the constraint information.
 21. Acomputing system in accordance with claim 15, wherein a product is oneor more of the number of courses associated with a menu, a food item, abeverage item or a combination thereof.
 22. (canceled)
 23. (canceled)24. (canceled)
 25. (canceled)
 26. A computing system for optimising andallocating bookings within one or more spaces in a venue, comprising: anallocation module including an optimisation algorithm in communicationwith a processor and arranged to receive at least one booking requestfor a table or table combination at a selected time period andcommunicate with a database of other saved booking requests, wherein,upon receiving the at least one booking request for the selected timeperiod, the allocation module determines whether a predeterminedthreshold value has been exceeded, and if so, the allocation moduleretrieves the other saved booking requests for the selected time periodand combines the at least one booking request with the retrieved bookingrequests to form a pool of requests, retrieves constraint informationregarding tables and table combinations, the constraint informationincluding first characteristics associated with each of the table ortable combinations within an area or sub-area and at least one set ofalternative characteristics associated with each one of the table ortable combinations within an area or sub-area, whereby the firstconstraints and at least one set of alternative constraints define aplurality of relativities, utilities, contextual relationships andcontexts between the area or sub-area for each one of the table or tablecombinations, and utilises the optimisation algorithm and the firstcharacteristics to order the pool of booking requests, the order beingutilised to iteratively allocate each of the requests from the pool ofrequests to one or more of the table or table combinations utilising theconstraint information to select the table or table combination, and ifthe booking cannot be allocated utilising the first characteristics, themodule utilises the at least one set of alternative characteristics toallocate the booking request to one of the table or table combinations,wherein an optimised allocation instruction set of tables and tablecombinations for the selected time period is produced, wherein theoptimised allocation instruction set is saved in the database andprovided by a space allocation user interface to one or more usersassociated with the venue.
 27. A computing system for optimising andallocating bookings within one or more spaces in a venue, comprising: anallocation module including an optimisation algorithm in communicationwith a processor and arranged to receive at least one booking requestfor a table or table combination at a selected time period andcommunicate with a database of other saved booking requests, wherein,upon receiving the at least one booking request for the selected timeperiod, the allocation module determines whether a predeterminedthreshold value has been exceeded, and if so, the allocation moduleretrieves the other saved booking requests for the selected time periodand combines the at least one booking request with the retrieved bookingrequests to form a pool of requests, retrieves constraint informationregarding tables and table combinations constraint information includinga first arrangement of the table or table combinations within an area orsub-area and at least one alternative arrangement of the table or tablecombinations within an area or sub-area, whereby the first arrangementand at least one set of alternative arrangement define a plurality ofrelativities, utilities, contextual relationships and contexts betweenthe area or sub-area for each one of the tables or table combinations,and utilises the optimisation algorithm to order the pool of bookingrequests, the order being utilised to iteratively allocate each of therequests from the pool of requests to one or more of the table or tablecombinations utilising the constraint information to one of the table ortable combinations utilising the first arrangement, and if the bookingcannot be allocated utilising the first arrangement, the algorithmutilises the at least one set of alternative arrangements to allocatethe booking request to one of the table or table combinations, whereinan optimised allocation instruction set of tables and table combinationsfor the selected time period is produced, wherein the optimisedallocation instruction set is saved in the database and provided by aspace allocation user interface to one or more users associated with thevenue.
 28. A computing system for optimising and allocating bookingswithin one or more spaces in a venue, comprising: an allocation moduleincluding an optimisation algorithm in communication with a processorand arranged to receive at least one booking request for a table ortable combination at a selected time period and communicate with adatabase of other saved booking requests, wherein, upon receiving the atleast one booking request for the selected time period, the allocationmodule determines whether a predetermined threshold value has beenexceeded, and if so, the allocation module retrieves the other savedbooking requests for the selected time period and combines the at leastone booking request with the retrieved booking requests to form a poolof requests, retrieves constraint information regarding tables and tablecombinations, the constraint information including first characteristicsassociated with each of the table or table combinations within an areaor sub-area and at least one set of alternative characteristicsassociated with each of the tables or table combinations within an areaor sub-area, whereby the first constraints and at least one set ofalternative constraints define a plurality of relativities, utilities,contextual relationships and contexts between the area or sub-area foreach one of the table or table combinations, and utilises theoptimisation algorithm to order the pool of booking requests, the orderbeing utilised to iteratively allocate each of the requests from thepool of requests to one or more of the table or table combinations,wherein the algorithm further determines whether a trigger has occurred,and if not, attempts to allocate the booking request to one of the tableor table combinations utilising the first characteristics, and if thetrigger has occurred, the module utilises the at least one set ofalternative characteristics to allocate the booking request to one ofthe table or table combinations, wherein an optimised allocationinstruction set of tables and table combinations for the selected timeperiod is produced, wherein the optimised allocation instruction set issaved in the database and provided by a space allocation user interfaceto one or more users associated with the venue.
 29. A computing systemin accordance with claim 15, wherein product attributes include a: a.date; b. service; c. booking time; d. number of guests; e. durationtime; f. and also include at least one of a: g. specific day of theweek; h. specific group size; i. specific occasion; j. specific durationfor a menu and/or courses; k. extended or reduced duration; l. specifictable; m. specific table attributes; n. specific location attributes; o.specific menu attributes; p. specific customer requirements; q. specificprice attributes; and r. specific service attributes.
 30. A computingsystem in accordance with claim 15, wherein the product informationincludes constraint information regarding supplementary items including:a. extended duration times; b. locations within a venue; c. classes oftables within a venue; d. specific types of table; e. specific tableswithin a venue; f. specific levels of service; g. tables with specificattributes; h. locations with specific attributes; i. menu specificattributes; j. service specific attributes; and k. promotion specificattributes.
 31. A computing system in accordance with claim 15, whereinthe product information includes constraint information regarding thirdparty items including: a. flowers; b. entertainment; c. changes to orderof service; and d. additional complementary products.
 32. A computingsystem in accordance with claim 15, wherein a price for a product isdynamically set in at least one of the following manners: a. Price byproduct; b. Price by product by time; c. Price by product group size; d.Price by occasion; e. Price by period of extended duration time; f.Price by peak and off-peak times; g. Price by table based on tableutility and table location characteristics; h. Booking fees; i. Price byadditional services; and j. Discounts and promotions during less populartimes.